Bug 55521 - Kernel misinterprets keypress and sends wrong X event
Summary: Kernel misinterprets keypress and sends wrong X event
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform_x86 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_platform_x86@kernel-bugs.osdl.org
Depends on:
Blocks: 56331
  Show dependency tree
Reported: 2013-03-20 23:33 UTC by Rudy Raab
Modified: 2013-11-13 21:30 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.7
Regression: Yes
Bisected commit-id:

My keycodes, reported by xmodmap -pke (9.66 KB, text/plain)
2013-03-20 23:35 UTC, Rudy Raab
Results from xev session (28.46 KB, text/plain)
2013-03-20 23:37 UTC, Rudy Raab
Results from second xev session (157.66 KB, text/plain)
2013-03-25 23:40 UTC, Rudy Raab

Description Rudy Raab 2013-03-20 23:33:26 UTC
On my laptop (Dell Studio XPS 1340), pressing Fn + Right arrow key is the hard-coded key for changing the brightness of the keyboard backlight. However when pressing this key on Linux (I use OpenSUSE 12.3 x64 with KDE 4.10) it sends the X message to disable touchpad and keyboard, forcing me to reboot (using a USB mouse to click GUI controls). 

My BIOS has no settings for this hotkey, and pressing it does NOT disable the touchpad in Windows 7 nor does it on the grub menu. 

I have attached my keycodes (as reported by xmodmap -pke) and a xev session in which I pressed the offending hotkey several times (with ktouchpadenabler unloaded).
Comment 1 Rudy Raab 2013-03-20 23:34:26 UTC
I forgot to mention-- I do not recall this happening in kernel 3.2 and below, so it may be a regression.
Comment 2 Rudy Raab 2013-03-20 23:35:40 UTC
Created attachment 95881 [details]
My keycodes, reported by xmodmap -pke
Comment 3 Rudy Raab 2013-03-20 23:37:35 UTC
Created attachment 95891 [details]
Results from xev session

I pressed the key combo several times in this session. Some of them were in the style Fn press - right arrow - right arrow - Fn release.
Comment 4 Aaron Lu 2013-03-21 05:20:47 UTC
Hi Rudy,

This doesn't seem to be a bug in acpica, instead, it feels more like a platform driver bug. I don't know much about how the hotkey is handled in your laptop, I'll re-assign this to platform-x86 category and hopefully they know what happened.
Comment 5 Rudy Raab 2013-03-25 23:40:17 UTC
Created attachment 96161 [details]
Results from second xev session

In this session the KDE Touchpad Enabler service is *disabled*, thus the X event for disabling the touchpad isn't carried out by anything. This time around it does catch XF86TouchpadOff events.
Comment 6 Rudy Raab 2013-03-25 23:42:23 UTC
I just ran another xev session, with the KDE touchpad enabler off. It actually caught the XF86TouchpadOff key press and release events this time. Strangely, it has several thousand press and release events even though I only pressed the key combination three times before closing xev.
Comment 7 Matthew Garrett 2013-03-25 23:44:20 UTC
None of the Dell drivers generate this event. If you do

watch -n 0.1 cat /proc/interrupts

which lines increase when you hit the brightness key?
Comment 8 Rudy Raab 2013-03-26 01:16:00 UTC
I couldn't see any lines changing when I pressed the key.
Comment 9 Matthew Garrett 2013-03-26 01:17:42 UTC
The one I'd expect to change would either be "1: (blah blah blah) i8042" or "9: (blah blah blah) ACPI".
Comment 10 Rudy Raab 2013-03-26 02:43:14 UTC
You were right; I didn't notice it at first but the CPU0 column in line 1 increments by 2 every time I press the key.
Comment 11 Matthew Garrett 2013-03-26 02:53:21 UTC
Ok, in that case this is a problem with the udev keymaps rather than the kernel driver. Unfortunately I can't reassign it there directly - you'll need to open a bug against udev at bugs.freedesktop.org.
Comment 12 Rudy Raab 2013-03-26 13:55:22 UTC
udev isn't on the list of products at bugs.freedesktop.org. Is that the correct place?
Comment 13 Matthew Garrett 2013-03-26 16:00:27 UTC
Ah, sorry - it's been subsumed into the systemd project now, so I think you need to file against that.

Note You need to log in before you can comment on or make changes to this bug.