Description of problem: Pressing 'ThinkVantage' button does not generate any events when running 'xev'. Version-Release number of selected component (if applicable): kernel-2.6.25-0.155.rc6.git8.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. start 'xev' 2. press 'ThinkVantage' button Actual results: nothing happens Expected results: a keypress even should be sent Additional info: this bug makes it impossible to bind 'ThinkVantage' key to do something useful via 'gnome-keybinding-properties'
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think this might be a userland issue: http://www.thinkwiki.org/wiki/ThinkPad_Button
When I press 'ThinkVantage' while running 'acpi_listen' command I get an event: $ acpi_listen ibm/hotkey HKEY 00000080 00001018 However when I run 'xev' or 'gnome-keybinding-properties', pressing 'ThinkVantage' does not generate any events. If this is not a kernel issue, to which component should this bug be reassigned?
thinkwiki link that you sent suggests the following: "A simpler but less flexible possibility than xbindkeys is "System -> Preferences -> Keyboard Shortcuts". Just go to (for example) "Run a terminal" and press the ThinkPad Button, when asked for a "New accelerator...". This is exactly what I was trying to do. When it asks for a "New accelerator..." I press 'ThinkVantage' button, but nothing happens, as if I didn't press any keys. Other key combinations work as expected.
I am definitely seeing the same problem on my Lenovo ThinkPad X61 running Fedora 9. The suggested thinkwiki page is useless: everything there assumes that the button is at least generating keypress events. It is not, as the original reporter noted when he described using xev. This only becomes a userland issue if userland has the opportunity to see something but is dropping it. No keypress events means no chance for userland to respond. I cannot run the acpi_listen test suggested in comment #3 because I don't have acpid running. Rather, I let hald take care of all that. In particular, hald-addon-acpi is reading from to /proc/acpi/event, and is the only process with that pseudo-file open. Running "strace -p $(pidof hald-addon-acpi)" reveals that hald-addon-acpi reads "ibm/hotkey HKEY 00000080 0000101" from "/proc/acpi/event" each time I press the ThinkVantage button. Unfortunately, is not subsequently doing anything useful with this event. "lshal --monitor" shows no interesting activity when I press the ThinkVantage button. It does show activity in response to volume keys, for example, so it's not completely dead. But it's nothing happens up at the hal event level in response to this button. Does this mean it's a hal bug, not a kernel bug? Perhaps. I have the vague sense that the hal developers intended to get out of the business of keypress management. I think they felt that stuff should just be managed by the kernel's input routines and the fact that it's also reported through ACPI didn't necessarily mean that their ACPI code should do anything about it. But I'm not certain of that. Perhaps it really is hal dropping the ball here. I don't know. Does anyone else have a hal connection and want to run this past those developers to see if they claim this as their bug?
This should be generating a keycode, and hal should then be remapping that to work correctly. The fact that it's not showing up in xev suggests that this is a kernel issue.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug has been fixed in Fedora 11