Problem with Dell SK-8135 volume control under evdev

[Linus Walleij]

I have a Dell SK-8135 with a a funny feauture: a volume knob mapped as
a secondary USB HID input device which will typically appear as
/dev/input/event2. Physically it looks like this:
http://www.df.lth.se/~triad/krad/SK-8135-knob.jpg

It's entry in /proc/bus/input/devices looks like this:
I: Bus=0003 Vendor=413c Product=2010 Version=0110
N: Name="Dell Dell USB Keyboard"
P: Phys=usb-0000:00:1a.0-1.1/input1
S: Sysfs=/class/input/input2
H: Handlers=kbd event2
B: EV=b
B: KEY=3878 c8015001 20000 0 0 0
B: ABS=1 0

I want to propagate events from this device from the Linux kernel to
the X Server, and from there to GNOME/KDE and other apps. This doesn't
work by default.

There is a small program named sk8135-pcm out there on the web, which
will use the raw kernel event interface and send volume changes
directly to ALSA and display an X overlay using XOSD. Perhaps this is
just as good as any other approach... But it displeases me. I don't
want to bypass the nice, layered software stack like that. It strikes
me as ugly and cannot integrate properly into the desktop systems.

The events on /dev/input/event2 come in properly. I've tested with
sk8135-pcm and some hacks of my own. The events being sent are of type
EV_ABS and code ABS_VOLUME. I have code like this:

/* check type/code of event */
if (ev[yalv].type == EV_ABS && ev[yalv].code == ABS_VOLUME) {
    printf("Value: %d\n", ev[yalv].value);
}

Which typically prints events like this:
Counter-clockwise:
-1
-3
-2
-2
-4
Clockwise:
3
3
2
2
1
2
etc.

I get partial success of bringing it into X with this xorg.conf entry:

Section "InputDevice"
        # This will likely match the volume knob of this keyboard any day
        Identifier  "Volume0"
        Driver      "evdev"
        Option      "Phys" "usb-*/input1"
        Option      "vendor" "0x413c"
        Option      "product" "0x2010"
        # This makes the first entry (the keyboard itself) take precedence
        Option      "Pass" "3"
EndSection

Result in log:

(II) evdev brain: Rescanning devices (1).
(**) Option "AlwaysCore"
(**) Volume0-usb-0000:00:1a.0-2.1/input1: always reports core events
(II) Volume0-usb-0000:00:1a.0-2.1/input1: Found 1 absolute axes.
(II) Volume0-usb-0000:00:1a.0-2.1/input1: Configuring as pointer.
(**) Volume0-usb-0000:00:1a.0-2.1/input1: Configuring in Absolute mode.
(**) Volume0-usb-0000:00:1a.0-2.1/input1: AbsoluteScreen: -1 is not a
valid screen.
[ skipped some lines ]
(II) XINPUT: Adding extended input device "<default pointer>" (type: MOUSE)
(II) XINPUT: Adding extended input device
"Volume0-usb-0000:00:1a.0-2.1/input1" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(**) Volume0-usb-0000:00:1a.0-2.1/input1: 1 valuators.
(II) Volume0-usb-0000:00:1a.0-2.1/input1: Init
(II) evdev brain: Rescanning devices (2).
(II) Volume0-usb-0000:00:1a.0-2.1/input1: On
(Full log: http://www.df.lth.se/~triad/krad/Xorg.0.log.txt)

X successfully takes the device, because now the command-line programs
never get any events.

Running "xev", focusing the window and rolling the knob doesn't result
in any events, sadly.

I've tried to read all apropriate man pages and docs I could find to
understand why the events won't propagate up to X. All help and
testing hints are welcome!

Yours,
Linus Walleij