Input device design (3)
krahn at niehs.nih.gov
Wed Aug 31 12:00:51 PDT 2005
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
> 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
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.
More information about the xorg