Input device design (3)

[Jim Gettys]

On Wed, 2005-08-31 at 02:56 -0400, 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.

Exactly, though I think the X server can find out itself when devices go
away: it will get an error on the file descriptor, so it isn't clear a
close message is needed (unless we want to be able to take away a device
already assigned to the X server...  Hmmm...)

Do people think we need to be able to retrieve input devices once
assigned to the X server.

> 
> 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.

It will probably work well on an unloaded system.  On a loaded system,
the latency will be quite variable.  And some *ix variants have very
brain dead schedulers, which have been optimized for things other than
interactive response.  So I'm not sure we can easily do such cross
platform tests.
			- Jim