Bug 55521

Summary:	Kernel misinterprets keypress and sends wrong X event
Product:	Drivers	Reporter:	Rudy Raab (bugspam)
Component:	Platform_x86	Assignee:	drivers_platform_x86 (drivers_platform_x86)
Status:	CLOSED MOVED
Severity:	normal	CC:	aaron.lu, alan, mjg59-kernel
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.7	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	56331
Attachments:	My keycodes, reported by xmodmap -pke Results from xev session Results from second xev session

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.