> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 21:00:27 EST