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