Summary: | thinkpad-acpi module does not correctly detect a Lenovo hotkey layout | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Smith <cdsmith80> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | rbu, wendallc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
dmesg output
kernel config Thinkpad keymapping detection code. |
Description
Christopher Smith
2007-10-13 00:54:40 UTC
Can you post your 2.6.23 kernel .config and dmesg output? You might want to use CONFIG_THINKPAD_ACPI_DEBUG if you haven't already, that may give us some additional info. (In reply to comment #1) > Can you post your 2.6.23 kernel .config and dmesg output? You might want to use > CONFIG_THINKPAD_ACPI_DEBUG if you haven't already, that may give us some > additional info. > I did make a mistake because I was switching back and forth between kernel 2.6.22 and 2.6.23. Apparently the PCI_ID is listed in the latest kernel's pci_ids.h file. I will try enabling debug mode to find out more information. Also I want to add that machine I am having issues with is a T60-1953 with intel graphics and intel wireless. Created attachment 133573 [details]
dmesg output
Created attachment 133575 [details]
kernel config
So, just to clarify, the problem is basically that pressing FnF3 turns the backlight off rather than showing battery status? Are you 100% sure that this functionality is controlled by the thinkpad_acpi driver? i.e. if you don't include that driver in your kernel, does FnF3 do nothing? does it generate any events in that configuration? Christopher, Have you had a chance to perform the tests requested in comment #5 ? The thinkpad-acpi module generates acpi events on FnF? keypresses. The keypresses are logged and I know they are generating events. I have been able to map the keys to scripts, one of which shows battery status. I can even get it to work with FnF3 but it doesn't stop the hard coded event from also happening. This is basically the problem. Particular FnF? keypresses are hard coded to specific events. FnF4 suspends, FnF12 hibernates, etc. The thinkpad-acpi kernel code has two different mappings, one for the older IBM style Fn setup where FnF3 actually is supposed to be screen blanking, and the newer one for Lenovo style Fn Keys where FnF3 isn't hard coded to blank the screen. The problem is that for some reason the mapping isn't being chosen correctly. I don't know enough about this to know if it is purely a kernel thing or if it is also related to something in userspace but I have seen the kernel code and was able figure out that the Lenovo style mapping is present in kernel 2.6.23 but is not being selected. I'm just not sure why. I am going to attach the section of code in from thinkpad-acpi that maps the two different layouts so you can see what I am talking about. Created attachment 135854 [details]
Thinkpad keymapping detection code.
The latest git-sources contains a patch that removes the generation of the EV_KEY KEY_BRIGHTNESS_UP/DOWN input events for the default Lenovo keymap. Can you please test with git-sources-2.6.24_rc5-r6 and post back the test results here? The Fn-F3 key is supposed to have different functions on different machines. There's more info in acpi-support's thinkpad-lockorbattery.sh -- copying from that: # Lenovo are great. They have changed the function of the Fn-F3 # combination on the LenovoPads from KEY_LOCK => KEY_BATTERY. # Unfortunately they didn't bother to change the DMI strings # consistently... so some of the new machines say 'LENOVO' and some # still say 'IBM'. Yay for consistency(!). # # (And just to top that, LENOVO have started producing non-ThinkPad # laptop computers). # So: # IBM && !Series60 => Lock # IBM && Series60 => Battery # LENOVO && ThinkPad => Battery Please reopen when you have had a chance to test with the latest dev kernel as requested in comment #9. I am using the latest Hardened and Gentoo sources (2.6.23-r5) and the problem seems to be fixed now. |