Comment 37 for bug 271706

Revision history for this message
ktemkin (kyle-ktemkin) wrote : Re: Volume control wheel on laptop is sticking in ubuntu

I don't think you're correct at all in diagnosing that the problem _isn't_ evdev. Making a few code modifications to the evdev driver to account for the odd scancode reporting fixes it right up, even if the volume control isn't as smooth as the windows version is. This definitely indicates that the problem is (at least resolvable) in evdev.

I think I'm repeating myself, but I'll explain basically how the scancode works on a normal keyboard key:

1) The keyboard (hardware) reports a scan-code indicating that the key has gone _down_. This indicates which physical key was pressed to the software.
2) The 'driver' software translates the scan-code to the correct key-press in the system locale and reports it to the shell/x-server/etc as a 'key event'.
3) The driver code waits a specific amount of time for another scan-code, indicating that the key has gone _up_. When this is not received, it sends another key 'event'.
4) Finally, the key is released, and the keyboard reports a scan-code indicating that they key has gone _up_. The driver stops paying attention, as it knows no (further) auto-repeat is required.

The problem is that when keyboards with media keys were first created, there wasn't an explicit media keys standard- many OEMs provided their own drivers. These keyboards, as often as not, did not bother to send key-up events for their media keys. After all, keys like "stop", "eject", "play', and etc. didn't really necessitate knowing when the key was released, only when it was pressed.

When the media key format became more standardized, both the windows drivers and the original X 'kbd' driver made a modification to their code, which automatically injected a key-up directly after a key-down for any media key. This 'hack' essentially turned of auto-repeat for media keys.

Up until Hardy Heron, Ubuntu utilized the older X 'kbd' driver- so you may notice that your volume keys work fine there. However, in the newer versions, the 'evdev' driver is utilized instead, which lacks the fundamental media-key-norepeat hack.

When I have time, I'll work on a similar hack for evdev- I have a prototype running on my machine (and several other users machines) that works perfectly, but I haven't had time to smooth out a few things (like the fact that this makes the volume 'keys' extremely oversensitive on the volume wheels of the U300 series.)