Comment 36 for bug 271706

I can confirm this issue, and I have a lot more information for whoever is pursuing this.

(I originally posted this in the following thread)
http://ubuntuforums.org/showthread.php?p=7385680#post7385680

This issue is not ubuntu-specific - I have witnessed this in gentoo too (and likely affects them all, based on this bug). (Bear with me)

I originally tried mapping the volume up/down keys to multimedia functions within gnome using XModMap within gentoo (basically creating aliases for special commands within Xorg), but then found the very same problem in gentoo - so I pulled off the keymaps and took a look for what was happening on keyboard input.

Fortunately, I was able to test a few more things within gentoo - but I can confirm that this issue is guaranteed to be from the same source as the problem within ubuntu.

I tried using xev, a program for watching input via event-based devices within xorg, and noticed that pressing either of the volume up/down keys on the R4125CA (R4000-series compaq laptop) causes one key signal while a volume up/down button is pressed, and the moment either of those is released, a completely different signal from the first is spammed endlessly - no other keypresses will stop this.

So, I tried using "showkey" from outside of Xorg, in a framebuffer console (basically command-line without gui ) . Interesting, pressing and holding a volume up creates two seperate scan codes - something that I would imagine to be EXTREMELY quirky (and a terrible hack?). I am not aware of any software for linux that will correctly interpret a double scan code. But I suggest that the developers for ubuntu might be able to file this information with whomever would be responsible for dealing with this.

Also important, this bug is present __with or without__ xf86-input-evdev ==> meaning that the problem has to start even before the keypresses are getting to Xorg's evdev driver. Perhaps in the kernel source for evdev ? *tear* :(

My locale and console region when dealing with this were EN-US and UTF-8.

As for the above issues of having the mouse pointer clicks not occuring - what I think I noticed was that following a volume key (for this device), a mouse click's signal is different, which explains why none of the mouse clicks after this event were working. (Don't take my word for it, I was watching the input scroll very fast - and can post a log if we need to confirm this)

I would also like to point out that physically inside this system, it appears that the multimedia buttons are not directly part of the physical keyboard, though they might get combined via hardware later on (Which could be the real source of this mess - and software would be how windows *ahem* is dealing with this issue)

I can also confirm that this issue exists on the livecd.

Just as a suggestion: I believe it was the ZV-6000 (i think compaq) has similar internals to the R4000 - perhaps this issue should contain this information as well for whomever is trying to test it.

If ubuntu needs more debugging information, I will be happy to test this further, since I'm quite interested in fixing this for everyone -- because this issue has been present for a LONG time in every distribution, and these buttons USED to work fine (can't remember when -- possibly during kernel 2.4 ? We can verify with older livecd's, as I recall it was fine on one of them in the past). Please reply if you want a complete log of scancodes/keycodes from showkey ouside of X.

Jet.