Adding input_id to udev

Adding input_id to udev

[Martin Pitt]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

Hello,

in the course of udevifying X.org, we determined that we need a
reliable way of detecting whether an input device is a touchpad (and
thus should be driven by -synaptics instead of -evdev). Our first
attempt [1] uses ATTRS{protocol}=="AlpsPS/2", but that misses a lot of
devices using other protocols.

So at least for now it would be better to actually check the
inputN/capabilities/{key,abs} flags in sysfs, like hal used to do.

I took the hal code as a basis and created an input_id program [2]
which detects the class of a device (since bit testing in udev rules
isn't possible). We can then use this in X.org's and potentially other
rules.

Questions:

 * Should we maintain this in udev proper, in extras/input_id/ ? (My
   preferred solution, since it's not really X.org specific). I'm up
   for maintaining it.

 * Should udev itself install rules which call this, or should we just
   provide it for other packages to use? Calling it in udev itself
   feels a little more robust to me, but it would mean that the
   probing would be done in vain on systems which use X.org with hal.

   Something like

   ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{program}="input_id /sys/%p"

   (I'll drop the /sys/ and move it into input_id.c before committing)

Thanks in advance for comments,

Martin


On my system:

$ gcc -o input_id input_id.c
$ for i in /sys/class/input/input*; do echo -n "--- $i: "; cat $i/name; ./input_id $i; done
--- /sys/class/input/input0: Lid Switch
ID_INPUT=1
--- /sys/class/input/input1: Power Button
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input10: Dell WMI hotkeys
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input11: HDA Intel Line In at Ext Left Jack
ID_INPUT=1
--- /sys/class/input/input12: HDA Intel HP Out at Ext Left Jack
ID_INPUT=1
--- /sys/class/input/input13: DualPoint Stick
ID_INPUT=1
ID_INPUT_MOUSE=1
--- /sys/class/input/input14: AlpsPS/2 ALPS DualPoint TouchPad
ID_INPUT=1
ID_INPUT_MOUSE=1
ID_INPUT_TOUCHPAD=1
--- /sys/class/input/input2: Sleep Button
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input3: Macintosh mouse button emulation
ID_INPUT=1
ID_INPUT_MOUSE=1
--- /sys/class/input/input4: AT Translated Set 2 keyboard
ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1
--- /sys/class/input/input5: Video Bus
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input6: Video Bus
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input7: HID 05f3:0007
ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1
##### ^^^ This is an USB keyboard, so this is correct.
--- /sys/class/input/input8: HID 05f3:0007
ID_INPUT=1
ID_INPUT_KEY=1
--- /sys/class/input/input9: Logitech USB-PS/2 Optical Mouse
ID_INPUT=1
ID_INPUT_MOUSE=1


[1] http://people.canonical.com/~pitti/tmp/66-xorg-synaptics.rules
[2] http://people.canonical.com/~pitti/tmp/input_id.c
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Adding input_id to udev

[Dan Nicholson]

On Mon, Nov 30, 2009 at 1:57 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Hello,
>
> in the course of udevifying X.org, we determined that we need a
> reliable way of detecting whether an input device is a touchpad (and
> thus should be driven by -synaptics instead of -evdev). Our first
> attempt [1] uses ATTRS{protocol}="AlpsPS/2", but that misses a lot of
> devices using other protocols.
>
> So at least for now it would be better to actually check the
> inputN/capabilities/{key,abs} flags in sysfs, like hal used to do.
>
> I took the hal code as a basis and created an input_id program [2]
> which detects the class of a device (since bit testing in udev rules
> isn't possible). We can then use this in X.org's and potentially other
> rules.

Awesome. I was hoping someone would pick this up.

> Questions:
>
>  * Should we maintain this in udev proper, in extras/input_id/ ? (My
>   preferred solution, since it's not really X.org specific). I'm up
>   for maintaining it.
>
>  * Should udev itself install rules which call this, or should we just
>   provide it for other packages to use? Calling it in udev itself
>   feels a little more robust to me, but it would mean that the
>   probing would be done in vain on systems which use X.org with hal.
>
>   Something like
>
>   ACTION="add|change", SUBSYSTEM="input", ENV{ID_INPUT}="", IMPORT{program}="input_id /sys/%p"

I think yes to both questions. It's pretty generic info, and I'm
pretty sure xorg wasn't the only one that wanted to consume it from
the hal database. I would also expect that any systems that have udev
(all linux) will be using it for the xorg config backend once it's
available. There was a lot of pushback from the extra "bloat" the hal
dependency added.

--
Dan

Re: Adding input_id to udev

[Martin Pitt]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

Martin Pitt [2009-11-30 10:57 +0100]:
> Questions:
> 
>  * Should we maintain this in udev proper, in extras/input_id/ ? (My
>    preferred solution, since it's not really X.org specific). I'm up
>    for maintaining it.

I discussed that on IRC with Kay today, and committed this to udev
trunk now.

>  * Should udev itself install rules which call this, or should we just
>    provide it for other packages to use? Calling it in udev itself
>    feels a little more robust to me, but it would mean that the
>    probing would be done in vain on systems which use X.org with hal.

It is in udev itself now, since it also helped to clean up
/lib/udev/rules.d/60-persistent-input.rules (look at the nice joystick
detection rule...).

I also made the following changes compared to the version of the
original mail:

 * Works on "eventN" (and similar) devices now, not on the parent
   "inputN" device. This is where you usually need them (in
   60-persistent-input.rules as well as X.org)

 * Argument should not specify /sys/ prefix any more, to be consistent
   to other probers, and for just using "input_id %p"

With those, the xorg rules do not need to jump through hoops to grab
the parent device's properties any more, and can just say

   ENV{ID_INPUT_KEY}=="*?", IMPORT{file}="/etc/default/keyboard"

or

   ENV{ID_INPUT_TOUCHPAD}=="1", ENV{x11_driver}="synaptics"

(The latter won't be used literally, since we still have some quirks,
but the structure is still easier than in the originally announced
rules.)

So now this needs to trickle into the distros, before X.org can rely
on it.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]