Comment 38 for bug 271706

In case you need beta testers, just let me know.

2009/6/3 ktemkin <email address hidden>:
> 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.)
>
>
> ** Changed in: linux (Ubuntu)
>       Status: Confirmed => In Progress
>
> ** Changed in: linux (Ubuntu)
>     Assignee: (unassigned) => ktemkin (kyle-ktemkin)
>
> --
> Volume control wheel on laptop is sticking in ubuntu
> https://bugs.launchpad.net/bugs/271706
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in xserver-xorg-input-evdev: New
> Status in “linux” source package in Ubuntu: In Progress
> Status in “linux” source package in Fedora: In Progress
> Status in Gentoo Linux: New
>
> Bug description:
> I'm running up-to-date intrepid. I have a volume control wheel on the side of my Toshiba U300 laptop. This volume control did work as expected in hardy. It operates like a scroll wheel on a mouse, in the way that it has specific points at which it sends a signal. When I got to these points on hardy, the volume would just increase or decrease by one block.
>
> With intrepid it gets the volume to go up one block, then waits for a second and then keep turning the volume up constantly without stopping. I've found if I hold a key on the keyboard down, for example Ctrl, it stops it temporarily. When I release Ctrl it start zooming off increasing or decreasing again. I have found if I swap desktops by holding down Ctrl Alt Left or Right, it stops it zooming off increasing or decreasing completely.
>
> I'm sorry if the above was a bit confusing. It's surprisingly hard to explain :)
>