Input device design

[Joe Krahn]

I have over the last several years made efforts to work with XInput, but 
never had sufficient knowledge of the X server internal design goals, 
and have been waiting for a LONG time for this to the top of Jim Getty's 
work pile.

I've written some of my ideas to http://wiki.x.org/wiki/XOrgInputDriverSpec
It seemed the interest has been too low. Maybe it's finally time to get 
going.

Questions and more ideas:

Are people in favor of implementing the traditional core devices as 
permanent virtual devices, with one or more real devices sending core 
events through the virtual devices? The virtual pointer would always be 
absolute, screen-resolution, and update with RandR.

There needs to be a system service that tracks available input devices. 
Should there also be an X client device manager that maps in those 
devices, sort of like a Window Manager? This would allow for user-prefs 
of devices names, sensitivities, etc.

It is a good idea to avoid using the system level combined pointer-input 
device /dev/input/mice, and let multiple devices be seen as multiple 
devices by X. The X client can then decide if a newly plugged in device 
should be accepted as a core-input device.

There's been a lot of discussion on how to map specific input devices. I 
don't think the X server should have to think about USB HUB routes, 
etc., to define a device. Input devices management should be a bit more 
like IP address / routing management. Devices get a name, possibly a 
generic DHCP-like name, and things like X that want to actually use them 
should require minimal knowledge of the hardware. Good/Bad?

There also needs to be a generic client/server protocol for input 
devices, which can be used to connect remote devices, emulate devices, 
or provide a way to connect new hardware that does not yet have proper X 
driver support. Something like UPnP is needed, but UPnP is overly 
complex for simple input device purposes, and still incomplete. Also, MS 
has a patent for device communication via XML. I was thinking of a 
trivial UPnP-like protocol using ConciseXML. ConciseXML is less verbose, 
and is IMHO a better fit to data than is regular XML, plus helps avoid 
conflicts with the UPnP people and/or the MS patent.

Joe Krahn