Re: The new X-Kernel !

[James Simmons]

> > at the problems GPM and X have had before. This problem gets more complex
> > as more pieces of software that play around with mice and keyboards 
> > emerges besides X or even while running in X. 
> 
> What is this non-X thing 8)

In the embedded market their is alot of GUI environments that are not X.
Working for a embedded linux company I come across many of them. Talking
to other embedded companies they all have the same answer. We will not use
X. They need something more portable and more powerful. A few off the top
of my head.

MicroWindows. 
Kaffe
Embedix   

Now before you say embedded devices don't use PS/2 mice and keyboards. I 
have a adapter to connect a PS/2 keyboard or mouse to the iPAQ at work. I
also have a alchemy board which allows you to plug in usb mice/keyboards. 

Plus for real game support I really like to see OpenGL use direct input.
Sorry but you need real time response in games. Have input events going
back a forth between the X cleint and the X server is just a waste.

> Seriously however most of this can be done well in userspace. The fact that
> X + gpm years ago got it wrong doesn't disprove the theory. 

As a said it is a matter of managing the hardware state between processes.
Consider a SMP machine that supports multiple desktops. Person on desktop
fires up a X server. It sets the hardware state of the keyboards and the
mice. The user runs apps that alter the state. The second user comes along
and log in on desktop two. He runs another small application to test the
mice. It changes the state which in turn effects the person on desktop
one.