Bug 23022 - Fn keys no longer control backlight on Sony Vaio SZ650
Summary: Fn keys no longer control backlight on Sony Vaio SZ650
Status: CLOSED DUPLICATE of bug 22722
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_other
URL: https://bugs.launchpad.net/ubuntu/+so...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-16 11:15 UTC by Michael Doube
Modified: 2010-12-09 21:48 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.37-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Michael Doube 2010-11-16 11:15:08 UTC
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
Comment 1 Jarod Wilson 2010-11-16 14:34:33 UTC
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.
Comment 2 Michael Doube 2010-11-16 15:54:20 UTC
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
Comment 3 Dmitry Torokhov 2010-11-16 16:58:30 UTC

*** This bug has been marked as a duplicate of bug 22722 ***

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