After this commit, the Fn+F5 and Fn+F6 hotkeys no longer control backlight on my Sony Vaio SZ650. It has been confirmed on a Vaio SZ4. This bug has made it into both Ubuntu 10.10 and Fedora 14. 8613e4c2872a87cc309a42de2c7091744dc54d0e is the first bad commit commit 8613e4c2872a87cc309a42de2c7091744dc54d0e Author: Mauro Carvalho Chehab <mchehab@redhat.com> Date: Thu Sep 9 21:54:22 2010 -0700 Input: add support for large scancodes Several devices use a high number of bits for scancodes. One important group is the Remote Controllers. Some new protocols like RC-6 define a scancode space of 64 bits. The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode translation tables, but it is limited to up to 32 bits for scancode. Also, if userspace wants to clean the existing table, replacing it by a new one, it needs to run a loop calling the ioctls over the entire sparse scancode space. To solve those problems, this patch extends the ioctls to allow drivers handle scancodes up to 32 bytes long (the length could be extended in the future should such need arise) and allow userspace to query and set scancode to keycode mappings not only by scancode but also by index. Compatibility code were also added to handle the old format of EVIO[CS]GKEYCODE ioctls. Folded fixes by: - Dan Carpenter: locking fixes for the original implementation - Jarod Wilson: fix crash when setting keycode and wiring up get/set handlers in original implementation. - Dmitry Torokhov: rework to consolidate old and new scancode handling, provide options to act either by index or scancode. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> :040000 040000 88897dc6073df285885f2a0e22f07833a55753f3 0ce85c424a2c7d36036959bb70702c544afa9b27 M drivers :040000 040000 6914657f7124ebf4ad170bbbbab4943bb2b91105 4b7036e9697c0e10d43c1d47111eef8877aa77be M include
Given that all the fn keys on my thinkpad still behave correctly, my initial thought is that there must be something unique the sony laptop key driver is doing here that maybe it shouldn't be, but that's pure speculation.
No idea if this helps, but I get the same key events when running acpi_listen Good kernel (2.6.36) mdoube@doris:~$ acpi_listen sony/hotkey SPIC 00000001 00000010 sony/hotkey SPIC 00000001 0000003b sony/hotkey SPIC 00000001 00000011 sony/hotkey SPIC 00000001 0000003b Bad kernel (2.6.37-rc1) mdoube@doris:~$ acpi_listen sony/hotkey SPIC 00000001 00000010 sony/hotkey SPIC 00000001 0000003b sony/hotkey SPIC 00000001 00000011 sony/hotkey SPIC 00000001 0000003b
*** This bug has been marked as a duplicate of bug 22722 ***