[Xorg] XInput Hotplug Additions
krh at bitplanet.net
Mon Aug 2 18:50:22 PDT 2004
Keith Packard wrote:
> Around 17 o'clock on Aug 2, Alan Coopersmith wrote:
>>So this extension is only usable by the Xorg server and other X servers
>>with their own configuration methods will not be able to use it?
> It does appear to rely a bit too heavily on the existing input device
> configuration mechanism and device handling.
> Even on Linux, I'd like to see the various protocol details handled
> exclusively by the kernel (this is already true with kernel 2.6) and have
> the X server use only "standard" /dev/input devices for input. This
> should eliminate almost all of the options listed in that request, leaving
> us with:
> XAddInputDevice (dpy, "/dev/input/event0");
I was aiming for a solution that would work with the existing range of
input drivers, but if that's not strictly needed, that's cool. It's
certainly easier and a more clean solution to let the X server probe the
device, but it requires that the OS provides such devices with
sufficient meta data available.
Anyway, I've mostly written the linux evdev driver, see
http://freedesktop.org/bugzilla/show_bug.cgi?id=968. It uses ioctl()'s
to discover what events the linux input device can generate and then
adds adds a server input device with the corresponding input classes.
It works for mice and keyboards at the moment, and I plan to add support
for absolute events, which should add touch screen support also.
> Configuration of the axis->button mapping should use the existing XInput
> device manipulation primitives, rather than being hard-coded when the
> device is added. This way all devices can be reconfigured on the fly
> without needing to go through a gratuitous unplug/plug cycle.
> Detection of appropriate drivers and protocols should be left to the X
> server/kernel. I'm not sure what we should do about naming; if the
> hotplug daemon can't even tell what kind of device is attached, it's going
> to have a hard time coming up with a reasonable name. On the other hand,
> having the X server attempt to construct a name means we'll be stuck with
> useless names most of the time.
The HAL based input-daemon example I have use the HAL UDI (unique device
identifier), which is a perfect example of a useless name. But it could
do better, it has the vendor name and product name available. But that
information is also available from the linux input device through
ioctl()'s, so the X server could also construct a better name.
More information about the xorg