Input device design (3)

[Joe Krahn]

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