Input device design

[Jim Gettys]

Now on the top of my list, barring looking for work, and dealing with
continuing fallout from a death in the family (e.g. I'm executor on an
estate unexpectedly).

Input events are limited by the rate of us slow humans: e.g. 100/second
or less.  Performance is *not* an issue in this application, and
claiming it is isn't true.

Better an extensible format that some ad-hoc binary format (says one who
has done both flavors of protocols).

We'd like input events to be generated by almost anything, down to and
including tiny devices running TinyOS (google TinyOS and Motes, to get
an idea of what is happening; we have a tiny device running with Zigbee
that lasts months on a single tiny battery) with a very minimal amount
of flash/ram, and up through Mac and Windows.  A dbus library footprint
is much larger than device crafted XML, for the few event types such
devices might generate (e.g. mouse motion).  Libdbus is > 200K bytes on
my machine, and while stripping out unused stuff might be possible, that
is likely a painful way to go.

Of binary formats that aren't too braindead, dbus comes to mind; but I'm
not convinced it is the right approach in this case, and it's been a
while since I looked at the wire format (a bit verbose, but so would XML
be). 

Rolling our own is possible, but a fair amount of work.  One other
approach is to see if one can externalize the Linux /dev/input interface
(much of the interface is via ioctl, rather than simple read/write of a
stream).

				Regards,
					- Jim



On Fri, 2005-08-26 at 04:16 +1000, Russell Shaw wrote:
> 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:(
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg