After looking at the debug sofar, my conclusion is that this is a problem not in the kernel driver sony-laptop, but at a higher level between acpi_fakekey and the desktop.
The facts are that Eject key events are being received by acpid:
1. We see the acpi log message:
[Sat Feb 2 12:52:31 2008] received event "sony/hotkey SPIC 00000001 0000001b"
..which means that sony-laptop is managing to detect the key and push the correct keycode (SONYPI_EVENT_FNKEY_E (which is 0x1b)) via kernel routine acpi_bus_generate_proc_event().
2. and that acpi_fakekey is pushing out the eject cd code 161 to a higher level.
3. The legacy driver sonypi detects the same port values (0x32,0x21) which the sony-laptop module handles in the same manner, meaning there is not a regression between drivers sonypi and sony-laptop.
I get the bug to the appropriate team that can handle this bug at the appropriate level.
After looking at the debug sofar, my conclusion is that this is a problem not in the kernel driver sony-laptop, but at a higher level between acpi_fakekey and the desktop.
The facts are that Eject key events are being received by acpid:
1. We see the acpi log message:
[Sat Feb 2 12:52:31 2008] received event "sony/hotkey SPIC 00000001 0000001b"
..which means that sony-laptop is managing to detect the key and push the correct keycode (SONYPI_ EVENT_FNKEY_ E (which is 0x1b)) via kernel routine acpi_bus_ generate_ proc_event( ).
2. and that acpi_fakekey is pushing out the eject cd code 161 to a higher level.
3. The legacy driver sonypi detects the same port values (0x32,0x21) which the sony-laptop module handles in the same manner, meaning there is not a regression between drivers sonypi and sony-laptop.
I get the bug to the appropriate team that can handle this bug at the appropriate level.