Input device design

[Russell Shaw]

Joe Krahn wrote:
> 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.

IMHO, it's a crappy idea to use verbose textual xml for communication
protocols. It's best for what it was designed: inter-application portability
of data, such as between word processors. Internal to an application like X,
a fast and compact (maybe even binary) purpose-built protocol optimized for
the application should be used.
Also, X should stay scaleable to small embedded devices, which precludes
throwing in gobs of xml parsers. Gtk going to xml to configure menus peeved
me off no-end:(