Comment 5 for bug 291878

I'm using a HP Pavilion zv6000EA and also experiencing this bug.

As for the behavior of the mouse button and the menu, I believe it's caused by the volume OSD (either metacity's or compiz's) appearing and preventing the menu from functioning properly. Also, a mere VT switch back and forth is sufficient for the "stuck" volume key to stop activating the OSD (no need to restart X). I've stumbled across similar bugs before where X thought that the Win key was pressed. Doing a VT switch back and forth helped there too.

I think this bug might actually be an old bug in the atkbd linux driver or similar, which hasn't bitten us until now because of the behavior of Xorg/hotkey-setup/whatever.

By running showkey -s in a VT, and from reading the man page, it seems scancodes are either 1-byte or 2-byte escaped sequences beginning with 0xe0. Pressing a key such as 'a' produces the 0x1e key-press scancode. If i hold the key for long enough, more 0x1e scancodes are produced, and when the key is finally released, a 0x9e key-release scancode is produced. It seems from looking at the codes that the corresponding key-release scancode for a certain key is always the key-press scancode + 0x80 (0x1e + 0x80 = 0x9e).

Some showkey -s output:
'a' key : 0x1e 0x9e
Mute key : 0xe0 0x20 0xe0 0xa0
VolDown key : 0xe0 0x2e
VolUp key : 0xe0 0x30

As seen above, the VolDown and VolUp keys produce 2-byte 0xe0-escaped key-press scancodes, but there are never any corresponding 0xe0ae or 0xe0b0 key-release scancode produced!

Looking at showkey -k, it is clear that the keycodes associated with the scancodes (automatically through hotkey-setup) never register a key release of the volume keys:

showkey -k output pressing (in order) Mute, VolDown, VolUp:
keycode 113 press
keycode 113 release
keycode 114 press
keycode 115 press

This behavior is identical in both kernel 2.6.24 from hardy (where the volume keys worked fine in Gnome) and the new intrepid 2.6.27 kernel. So I believe that some change in either Xorg or somewhere else made it actually care about the key-release event never being produced and interpret that as the key being held down (even though no additional key-press keycodes are produced).

For reference, xev in X yields the following (repeating forever until i VT switch back and forth) when i press VolUp:

KeyPress event, serial 30, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276245, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276748, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276748, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276798, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276798, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x9e00001,
    root 0x67, subw 0x0, time 6276845, (83,-15), root:(88,50),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Also, for reference, my mute button only procuces its 2 2-byte scancodes upon key release. Nothing at all is produced until i release the key, so it is impossible to "hold the key down" and get more than one event in showkey -s or showkey -k. Not sure if this is hardwired in hardware or in the atkbd linux driver...

Judging by the man page of setkeycodes, it doesn't seem to support keyboards not producing key-release scancodes for certain keys, since you only give one scancode (the key-press one) as input (and it figures out the +0x80 key-release code on its own...). Therefore, my guess is that this should be fixed somewhere in the kernel via a quirk to automatically yield a 0xe0ae scancode after every 0xe02e and 0xe0b0 after every 0xe030. Maybe there is already a similar quirk responsible for my mute button behavior mentioned above?

Cheers,
Rikard