retitle 185450 missing some sort of replacement for virtual terminal ioctl's thanks
On Wed, Mar 19, 2003 at 10:41:05PM +0100, Marcus Brinkmann wrote: > > > > > > It needs to be cooperative, but it can be simple. It also can assume trust > > > between the communication partners (ie proper behaviour). > > > > I don't see the whole picture. how are the console client and X server > > accessing the keyboard and screen resources Mach provides? > > The VGA card is accessed directly. Just look into the code it's right > there. (hurd/console-client/vga-hw.c for example). > > The keyboard is accessed directly, too. There is a simple driver in the > kernel though so the interrupt handling is done inside the kernel. and the Xserver is also accessing VGA and keyboard directly? looks like an unnecessary code duplication to me. i think it'd be interesting to develop a keyboard and an vga/text driver as part of the user-drivers project [1]. the vga/text frontend interface looks a bit complicated but the keyboard is more straightforwarded (just provide key codes with make/break for reading, and ioctls for weird things like leds) [1] http://savannah.nongnu.org/projects/user-drivers > The mouse would be accessed directly, too, like the keyboard (for PS/2), or > via the com device (for serial mouse). I was thinking that for the mouse > the console client should probably act as a repeater like gpm can do it. IIRC, Xserver always uses /dev/mouse, which is /hurd/mouse with the parameters to either use a serial mouse in /dev/com0 or a PS/2 one directly. does the console client have mouse support yet? > No, they access it directly and must negotiate about releasing resources > before the other can grab them. For the mouse, I think that maybe it should > be different. Oh, maybe for the keyboard as well. if a translator for each of screen, keyboard and mouse monopolises its access, then it's easy to disallow more than one client to use it at once, and coordinate them. > But you can not > reasonably have display device access through a proxy, i don't understand.. why not, latency problems? > except if you are > going to write a framebuffer device, and then still you are going to want > something better for direct rendering etc. i'm lost with this.. please could you explain? :> -- Robert Millan make: *** No rule to make target `war'. Stop. Another world is possible - Just say no to genocide _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
