Input device design
rjshaw at netspace.net.au
Thu Aug 25 11:16:39 PDT 2005
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
> 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:(
More information about the xorg