Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> The question is which software is to blame for the bug. The kernel for not
> using a rock-solid locking mechanism? The application(s) for having to
> implement independent device driver instances touching the same hardwae
> in preemptive code sections?

It was needed for it time. Now things are evolving in another direction so 
things will be done right in time.
 
> Even if they handle switches 'correctly' from a software-theoretical point
> of view they could get scheduled in the middle of setting up the hardware.

Right. I have patches avaliable for fbdev and the console system to fix
this which I will place in cvs soon :)

> Scheduling or suspending (at user's request) applications using DRI is not,
> and I wonder how the DRI developers intend to fix that cleanly.

Userland locks. If you get scheduled away no other process doesn't get
access to the video hardware. This is of course means you cross your
fingers and hope the apps obey the locks. In the DRI approach the OpenGL 
library handles all this. In other words the attitude is use the OpenGL
library supplied by DRI. Don't do your own thing :(

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net