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
--
Notebook Volume Up/Down Buttons Misbehaving
https://bugs.launchpad.net/bugs/291878
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
