Bug 439075 - 'ThinkVantage' button does not work on ThinkPad
'ThinkVantage' button does not work on ThinkPad
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: John Feeney
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-26 16:14 EDT by petrosyan
Modified: 2013-01-10 02:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-17 16:24:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Novell 408815 None None None Never
Launchpad 190258 None None None Never
Launchpad 217504 None None None Never

  None (edit)
Description petrosyan 2008-03-26 16:14:06 EDT
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'
Comment 1 Bug Zapper 2008-05-14 02:54:03 EDT
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
Comment 2 John W. Linville 2008-05-21 11:12:01 EDT
I think this might be a userland issue:

   http://www.thinkwiki.org/wiki/ThinkPad_Button
Comment 3 petrosyan 2008-05-21 11:39:29 EDT
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?
Comment 4 petrosyan 2008-05-21 11:45:12 EDT
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.
Comment 5 Ben Liblit 2008-08-20 17:08:24 EDT
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?
Comment 6 Matthew Garrett 2008-09-05 04:50:30 EDT
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.
Comment 7 Bug Zapper 2008-11-25 21:10:57 EST
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
Comment 8 petrosyan 2009-05-17 16:24:45 EDT
This bug has been fixed in Fedora 11

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