Re: Bug#185450: missing virtual terminal ioctl's

[Robert Millan]

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