> kernel: while I know that things like GPM etc use mouse devices directly,
> I'm personally convinced that in the bigger picture the only thing that
> really matters is X.
For those of us working on embedded platforms X is not the answer. In fact
X is a cause of much mirth merriment and laughter when you try and mix even
the tinyX works memory foot print with such devices.
(The 'but they get bigger' argument doesnt work too. In the PDA work right now
sure but in general - no. They don't get bigger they get -cheaper-, if your
print manager box uses 8Mb less ram it costs less to make and you undercut
the other guys)
Ironically, the input device isnt what you want for an embedded box either. Its
too generic and it increases the footprint again. Handling just the devices
actually there in whatever isnt X11 will do fine.
> And X handles multiple input devices quite nicely, these days. That didn't
> use to be the case. So the advantage of having an input layer in the
> kernel is greatly diminished - and basically nonexistent if X still has to
> be able to do different mice.
Who managers which mice, keyboards and screens go to which display ? Putting
multiple monitors/keyboards/mice on a pc is becoming trendy. This is the one
thing I think input helps with a lot (we also have to fix the current
virtual console model which has a very 'one keyboard, one screen. one user'
model for things like security.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:06 EST