[Xorg] XInput Hotplug Additions

[Kristian Høgsberg]

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.

Kristian