Input device design

[Jim Gettys]

On Thu, 2005-08-25 at 14:45 -0400, Joe Krahn wrote:

> 
> Jim Getty's suggested XML, with the argument that input-event data is 
> small enough that the overhead/waste is minimal. I'm suggesting 
> ConciseXML because it's less overly-verbose than 'real' XML.

Could be.

I just did a back of the envelope computation, that concerns me:

Say 100 events/second, at 100 bytes/event, say, in round numbers ==
80,000 bits/second.

The issue is that technologies like zigbee are at the 200Kbit/second
range, and the latency is too large (a good fraction of a second).  

That implies that a XML text format had better be compressed (XML
compresses extremely well, but we should get some actual numbers).
Don't presume binary protocols are more compact than text ones, btw:
IIOP (the infamous CORBA wire protocol) has a minimum message size of >
100 bytes!!!

Hmmm, I better also go think about the TCP/IP framing; maybe we have to
go back to the future and do VJ header compression on such links; maybe
the TinyOS folks have already done so....  I'll check with my local
experts.

So by this argument, we do need a very compact representation, but note
that due to compression (e.g. zlib) this doesn't say much about whether
it would be binary or text.

> 
> A binary alternative could probably be based on this: 
> http://home.ifi.uio.no/~dinkoh/

Thanks for the pointer.  A quick look makes it obvious this is worth a
read.

> 
> IRIX uses a shared-memory queue to feed event data to X. Maybe some 
> ideas could be gotten from looking at IRIX.
> 

Most early X servers used this sort of mechanism.  But it is typically
pretty inflexible.

However, I would argue we should go for a modular bottom end, capable of
translation from various event types, e.g.: serial devices, like a lot
of our legacy stuff, /dev/input (or equivalent on various systems), and
events coming from some network based input device.  Events would go
through such a module from their source, be translated to the procedural
interface XInput needs (with any modifications we may need; abstract
naming of valuators is one that Kristian identified), 

So long as we take this sort of modular approach, we can do this
incrementally, and not hold the immediate needs of hot plug of local
devices to the long term goal of network input devices.  I suspect
security issues will make network based input devices take longer, and
our user community needs hot-plug *now*, not a year later while other
issues are solved there.

But this much modularity needs to be designed in in the reimplementation
of the input stuff.

And I don't want all input events routed through a secondary input
process, as that has bad effects on latency (we can't guarantee that
such a helper process gets scheduled at the right moment, and latency
variability drives people nuts in interactive situations).  So through
such a module, the X server would call all the way down to the input
device or socket (depending on input type), and not be subject to such
variability.

External programs from the input server (e.g. the modern desktop systems
using HAL/DBUS), or a daemon whose job it is to listen for new network
devices, would get initial control of devices on hot plug, potentially
do initial setup, and then hand them off to the X server (since you can
send sockets through the socket interface).

				Regards,
					- Jim