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

[Marcus Brinkmann]

On Thu, Mar 20, 2003 at 01:35:30AM +0100, Robert Millan wrote:
> > 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.

What code do you think is duplicated?  open ("/dev/mem") and mmap () or
vgamem[index] = value?
 
> 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

A framebuffer would be interesting.  Apart from that, we already have the
right separation.  If you disagree you should consider the disadvantages of
indirect access to, for example, the keyboard scan codes.  You would want
all the features that are already in X, like switching between input maps.

Now, you can say that all projects need these features, and a common server
with a nice interface (which suddenly becomes much more complicated than a
ioctl for leds) would benefit them all.  But what projects could that be?
The console, XFree86, and what?  Fresco?  There it pretty much ends.

> > 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.

You are talking about the status quo.  But the status quo is nothing to be
concerned about, nor is it a good example how it should be.

However, the console client mouse driver could provide /dev/mouse.
 
> does the console client have mouse support yet?

No, mostly because there is not cut&paste 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.

That's easier said than done.  Maybe you should think a bit more about it.
Problems pop up all along the way from having the idea to putting it into an
implementation.  Some pointers to potential problems are in the console
threads I had with Roland.
 
> > But you can not
> > reasonably have display device access through a proxy,
> 
> i don't understand.. why not, latency problems?

Performance problems in general.  You can not abstract the hardware in a
general interface and still have direct rendering.  Unless you are only
talking about wrapping direct hardware access into a wrapper for convenient
resource management.  Which would then only be syntactically different from
what we decided to do.

> > 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? :>

In some cases you want to access the hardware directly for maximum performance.
For example video streaming.

I can only recommend to reread the console discussion, and then if you have
a good idea (like the one above), start to actually think through how you
would implement it.  As soon as you start to write down what components you
want, and how they interact, you can start to think about border and race
conditions, and what happens if you start to include desirable features.

You can not discuss the problems of an idea like this based on one or two
sentences describing the idea.  You have to work on it at a much finer detail.
>From my experiments, some details of the console server/client designs were
only clear to me after a couple of months of starting the actual
implementation.  I wouldn't expect it to be different for other similar
ideas.  Only so much: The plan as I have outlined it is a clear and
restricted project: The cooperative protocol for console switching is easy
to design and implement, and we know that it will do well.  Whereas what you
hinted at is a full scale separate project more like kgi, and it's not at
all clear what is the correct approach to that, or how it can be put into
something usable and useful.  In other words: If you are interested in the
hacking, then go ahead.  But if that is something you want to do, you can
put < 0.1 % of the time that would go into that and do the cooperative
console switching as a warming up exercise.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/