Input device design

[Joe Krahn]

Jim Gettys wrote:
>  >
>  > 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.
I wasn't thinking of shared memory, as much as how IRIX generalizes 
input devices to the X server.
> 
> 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, essentially keep input modules as they are, right? But hopefully get 
back to correctly using the DeviceControl function instead of the 
current mangled stuff?
> 
> 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.
So, forget about network devices/protocols for now. We first need to 
make decisions on XDeviceList handling, and run-time module 
loading/unloading, and the required changes to XInput.

SO, lets get some XOrg Wiki editing going, even if it's just the 
addition of unorganized comments at the bottom:

http://xorg.freedesktop.org/wiki/XInputHotplug
http://xorg.freedesktop.org/wiki/XOrgInputDriverSpec
http://xorg.freedesktop.org/wiki/XInputSpec

> 
> 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.
OK. Good to have some informed feedback.

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

I assume we can also send file descriptors, so that X doesn't even have 
to know that "Logitech Optical USB Mouse" comes from /dev/input/mouse3 
today and /dev/input/mouse2 tomorrow.

This way, the servers view of a device could be a name, a protocol, and 
possibly a UUID for devices that can be uniquely identified.

Joe