Input device design (3)

[Jim Gettys]

I worry hard about latency variation in a separate input process on
loaded machines, if all events go through an extra process.  And process
schedulers have often been/are often brain-dead.  It might be good
enough on Linux, but I have less confidence it will be "good enough" on
all the platforms we support.

Certainly, a wire protocol we could choose could be the X event
structures themselves, but I think if you go look at them, you'll see
they are sometimes very ugly for input events, due to the 32 byte
limitations on the size of X events (again, something I'd do differently
if we could start with a clean slate, but we can't).  And we may have
input events that the X server itself doesn't really understand.

And we need some encoding mechanism for device controls that can encode
information that may be opaque to the X server, but understood by the
input device. This is for things like calibration data, force feed back,
and so on, that may be understood by an an application that the vendor
of the hardware might provide and be understood by the input device
itself, but nowhere in-between.

I would argue that introducing a new input device type that is a
superset of existing devices should not necessarily require
modifications to X itself, at least to the extent that the subset is
well known.   We don't want to bottleneck innovation in input devices.

One of the nice things about XML formats is that this sort of
encapsulation of such information is possible, with a section X
understands, and something private to both client and input device.

I'm currently trying to figure out if the low end wireless performance
poses any sort of bad constraint on input message sizes....
				- Jim



On Wed, 2005-08-31 at 15:00 -0400, Joe Krahn wrote:
> James Cloos wrote:
> > BTW, just to be clear, I (at least) wasn't thinking of having the
> > actual i/o events go through this os-dependant, external server,
> > but rather just the initial discovery and hotplugging of i/o devices.
> > 
> > I was expecting the external server to notify the X server of the
> > locations of the devices.  Ie, on Linux it could tell the X server
> > that /dev/input/event5 just appeared, is a pointer, and should join
> > the set of core pointers.  Or that eg /dev/input/event2 went away
> > and should be close(2)ed.  Et cetera.
> > 
> > Routing the actual input events through such an external server seems
> > like too much overhead and latency, though I could easily be wrong;
> > perhaps that is after all the best option for input devices, if not
> > for output devices (screens, speakers, readers, braille, etc).
> > 
> > Someone should test it out and see how well -- or not -- it works in 
> > practice.
> > 
> > -JimC
> > -- 
> > James H. Cloos, Jr. <cloos at jhcloos.com>
> 
> I originally thought of keeping actual device I/O internal to X. But, 
> this is an area where hardware diversity can make X code rather ugly.
> 
> Having thought about having external raw I/O separate, my current 
> thought is that event packets can be packaged to to the same event data 
> formats used by X clients. The code is all there, and will also be there 
> when new event types are defined.
> 
> I think the overhead is minimal. It is one more IPC exchange at most. An 
> external low-load I/O daemon handling SIGIO from many devices might even 
> be a good thing.
> 
> I proposed the possibility of "Direct Input" from the I/O daemon in 
> cases where latency is important. But, I suspect it will seldom be 
> noticeable.
> 
> One disadvantage of an external I/O daemon is that you lose the 
> permission bits of the /dev nodes. However, it seems to me that the 
> current approach of dynamically changing these permissions via 
> console.perms is inadequate for dealing with multiple VTs/X-servers.
> 
> Joe
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg