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).
I forgot to mention-- I do not recall this happening in kernel 3.2 and below, so it may be a regression.
Created attachment 95881 [details] My keycodes, reported by xmodmap -pke
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.
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.
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.
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.
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?
I couldn't see any lines changing when I pressed the key.
The one I'd expect to change would either be "1: (blah blah blah) i8042" or "9: (blah blah blah) ACPI".
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.
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.
udev isn't on the list of products at bugs.freedesktop.org. Is that the correct place?
Ah, sorry - it's been subsumed into the systemd project now, so I think you need to file against that.