inputd vs. hal
Johannes Berg
johannes at sipsolutions.net
Thu Aug 10 01:08:54 PDT 2006
Hi all,
I wanted to do one trivial thing last night: change my display
brightness using the keyboard and noticed that it didn't work anymore.
It used to work with gnome-power-manager by hal broadcasting that I
pressed brightness-up or brightness-down.
After scratching my head for a while I realized that the problem was
that I had inputd running. For the uninitiated, inputd is a small,
currently experimental, daemon written by Michael that grabs all
/dev/input/event* devices exclusively, and for each one creates (using
the uinput facility) a new virtual one. The point is to allow having
things coming from two different input devices be joined together into a
single event. A useful example (and currently the only thing
implemented) is having CTRL+left-button map to right-button for a mouse
or more importantly the touchpad on the powerbooks. Also, inputd is
intended to replace the kernel facility for creating a virtual middle
and right mouse button on ADB based Apple laptops.
Now, since inputd was running, it had grabbed all /dev/input/event*
devices so that hal didn't get any events from them any more. Note that
of course hal was notified about the fact that new devices showed up,
but none of them were actually bound by any hald-addon-keyboard because
none of them had a physical device link since they were virtual.
I'm uncertain about how to handle this. It will obviously require a hal
modification because it is essential that hal pick up events from such
virtual devices that were added for each physical device. inputd takes
care to create a device with the same descriptor as the original (same
bustype etc), it only prefixes the device name with "[inputd] " at the
moment. However, there doesn't seem to be a clean way of detecting the
fact that a device is virtual, other than deducing from the fact that it
has no physical device link yet is USB ;)
Possibly the best solution would be to define a new BUS_VIRTUAL constant
and force all uinput devices to that from the kernel, and add it to the
switch statement in hal's probe-input.c (the one that I previously
cleaned up :) )
Thanks for reading,
johannes
More information about the hal
mailing list