[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#185450: missing virtual terminal ioctl's
From: |
Robert Millan |
Subject: |
Re: Bug#185450: missing virtual terminal ioctl's |
Date: |
Thu, 20 Mar 2003 01:35:30 +0100 |
User-agent: |
Mutt/1.5.3i |
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#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/19
- Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's,
Robert Millan <=
- Processed: Re: Bug#185450: missing virtual terminal ioctl's, Debian Bug Tracking System, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/19
- Re: Bug#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/20
- Re: Bug#185450: missing virtual terminal ioctl's, M. Gerards, 2003/03/20
- Re: Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/20
- Re: Bug#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/22
- Re: Bug#185450: missing virtual terminal ioctl's, Marcus Brinkmann, 2003/03/23
- Re: Bug#185450: missing virtual terminal ioctl's, M. Gerards, 2003/03/20
- Re: Bug#185450: missing virtual terminal ioctl's, Robert Millan, 2003/03/22