> > Lights on keyboard are not input.
> So we are going to have a protocol with _no_ bi-directionality? That dosn't
> make much sense, IMHO -- even (old-school) printers can report out-of-paper,
> offline, etc. Keep simple bi-directionality. It shouldn't break the
> protocol -- if it does, then it was an _awfuly_ brittle protocol.
> > Also, we should make the interface as simple as we can, hiding all the
> > hardware stupidness in the kernel.
> I supose -- If they realy want to see all that stupidity, let them ioperm()
> themselves up the wazzo.
Hold on! Are you sure you know how big the can of worms you
are opening is?
Take mice with wheels, for example. The wheel typically needs
to be enabled somehow. This is done by writing to the device.
(The latest XFree86 does that). If you want to provide a
generic interface to input devices, and get rid of the "raw"
devices, you will also have to take things like this into
account. Not to mention all the input devices that haven't
even been invented yet. What happened to the "do as little as
possible in the kernel" paradigm.
Somehow, I get the feeling that things haven't been
sufficiently thought out at a general level before diving into
the little details like bit positions in protocols.
I'm also not sure of the benefits of this grand unified input
protocol is. Is the current way of handling things that
broken? It won't make the installation process any easier,
because you will still, for example, have to specify mouse
protocol and keyboard layout.
I also don't see the point in trying to bundle every single
input device under the same interface. For example, do
keyboards necessarily have to use the same protocol/interface
as pointing devices?
Johan Myreen
jem@iki.fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu