I just bisected a regression down to: commit b4b583d4e9a5ff28c4a150bb25a4fff5cd4dfbbd Author: Jiri Kosina <jkosina@suse.cz> Date: Mon Oct 31 16:26:22 2011 +0100 HID: be more strict when ignoring out-of-range fields I have a logitech USB keyboard with extra inet/media keys. In kde I have them configured to launch various utilities. With this commit, these keys will "stick", and instead of a single konsole window or krunner dialog or whatever, it continues launching konsoles or toggling the krunner dialog on and off. Switching to a text VT and killing X gets me the system back, but of course without X, and launching X/KDE over again results in unresponsive hotkeys. Apparently, one of these "out of range" fields translates to a key-release for at least some of the extra keys, without which they stay pressed and auto-repeat. gentoo/amd64 system, logitech wireless usb keyboard, kde 4.7.97 (aka 4.8-rc2), xf86-evdev-2.6.0, xorg-server-1.11.3. I can attach .config later (headed to work now).
Created attachment 72189 [details] kernel config I just confirmed that reversing that commit against 3.3.0-rc1-167-gf8275f9 eliminates the issue, so it is definitely that commit triggering it. Meanwhile, here's my current kernel config as promised.
The problem remains as of 3.3.0-rc2-172-g23783f8. Reverting still eliminates it.
Bug seems to have been overlooked in the 3.2 -> 3.3 regression list. Adding the block on the tracker bug and changing the summary to reflect the regression will fix that, I hope. AFAIK the bug is still here on rc5. I've applied the regression patch locally tho, so have to manually verify it with a reset to upstream, build and boot to X/KDE, from time to time. Last I did, it was still unfixed.
First-Bad-Commit : b4b583d4e9a5ff28c4a150bb25a4fff5cd4dfbbd
Patch : http://www.spinics.net/lists/linux-input/msg19542.html
Confirmed, that fixes my problem here, too.
Fixed by commit 883e0e366209067e690356e58e19bb2e6693b839 .