[Hardy] ThinkVantage key no longer working

[Tom Vetterlein]

The ThinkVantage key does no longer work.

This problem has been discussed at the thinkpad-acpi upstream mailing list at: http://<email address hidden>/msg01128.html

This bug is present in:

 - hardy (2.6.24)
 - intrepid (2.6.28)

Affected modules:
  - R61
  - X60s

[Tom Vetterlein (smbm)]

I've selected linux as the package after reading guidelines at https://wiki.ubuntu.com/Bugs/FindRightPackage

[Tom Vetterlein (smbm)]

There seems to be some more info here:

http://<email address hidden>/msg01120.html

Not sure how to proceed with the fix myself. Can anyone offer any insight?

[Leann Ogasawara (leannogasawara)]

Hi Tom,

Care to take a look at the following wiki and provide the keycode for your ThinkVantage key? https://wiki.ubuntu.com/LaptopTestingTeam/HotkeyResearch . Also per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

[Tom Vetterlein (smbm)]

I'm pretty sure it should be mapped to 0x9f.

I've managed to work around it using an ACPI hack but it's not ideal.

I'm running a:

LENOVO
77321EG
ThinkPad R61

(The results of the dmidecode commands on the wiki)

Here are the required attachments:

[Leann Ogasawara (leannogasawara)]

Hi Tom,

Looks like your dmesg cache filled up. Care to recaputre and attach your dmesg output after a fresh boot. Also, I think the newer 2.6.24-8 kernel was released. You might want to test just to verify the issue still exists. Thanks.

[Tom Vetterlein (smbm)]

Hi

I will do that asap, I have a batch encoding job running at the mo though so it might be a little while.

Installed the new kernel earlier. I tried a quick test but my ad-hoc ACPI hack seems to be overriding the thinkpad_acpi module (if that is indeed what is responsible for mapping the Thinkwiki key) so I'll try and reverse that when I get a bit of spare time.

It's all a little confusing, there seems to be several different ways to assign a function to a key. I don't know enough about thinkpad_acpi to know if it was really that that was at fault or something to do with ACPI.

Any ideas?

Thanks.

[Reinhard Tartler (siretart)]

I can confirm this bug, and I'm attaching a dmesg from my machine (Thinkpad X60s).

[Reinhard Tartler (siretart)]

confirming bug. Likely duplicates:

bug #90810
bug #164981
bug #199502

[Reinhard Tartler (siretart)]

raising importance since this is a regression

[Sven Bachmann (basv)]

I can confirm it on my X60s.

I see no output from the "xbindkeys --key" or the "xev". But if I do a "cat" on /dev/input/event6 which is assigned to the thinkpad_acpi module, it show some output when I press the ThinkVantage key - but the power button shows nothing.

[Josh Hayden (josh-hayden)]

Confirmed on my Z60t.

No output from "xbindkeys --key" or "xev", as above.

[fantong (fantong77)]

hi all
Is there any schedule to solve the problem?

[Reinhard Tartler (siretart)]

> Is there any schedule to solve the problem?
first the cause needs to be found, as this bug only describes the
symptoms. Then a developer can fix this issue.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Tom Vetterlein (smbm)]

It shouldn't be too difficult to fix, you would just need to insert the appropriate acpi_fakekey command in:

/etc/acpi/thinkpad-thinkpad.sh

I think the Thinkvantage key is supposed to map to 0xf9, I've no idea which acpi_fakekey number this is so I'm just using

acpi_fakekey 155

which seems to work.

That's what I'm using for a workaround anyway.

I just don't have the skills/time to learn how to do it myself at the moment.

[Sven Bachmann (basv)]

Hi,

Tom Vetterlein wrote:
 > It shouldn't be too difficult to fix, you would just need to insert
 > the appropriate acpi_fakekey command in:
 >
 > /etc/acpi/thinkpad-thinkpad.sh
 >

thank you Tom! This brought me further to:

sudo setkeycodes e073 148

After that, the key works without the need to modify the
/etc/acpi/thinkpad-thinkpad.sh file.

So its mainly a problem of a not mapped keycode. This mapping is done
in hotkey-setup. If I find out more, I'll mail again.

Bye,
   Sven

[Josh Hayden (josh-hayden)]

After "sudo setkeycodes e073 148"...

"xev" output:
KeyRelease event, serial 31, synthetic NO, window 0x3e00001,
    root 0x59, subw 0x0, time 2730321, (169,-12), root:(176,39),
    state 0x0, keycode 159 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

"xbindkeys --key" output:
Press combination of keys or/and click under the window.
You can use one of the two lines after "NoCommand"
in $HOME/.xbindkeysrc to bind a key.
"(Scheme function)"
    m:0x0 + c:159
    NoSymbol

Using System > Preferences > Keyboard shortcuts, the key shows up as 0x9f. However, it does not work if assigned to any action. Anyone have any luck with this?

Josh

[Josh Hayden (josh-hayden)]

Well, it seems to work for some actions. However, it does not work for "Run a terminal", which I've always used it for.

Josh

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Reinhard Tartler (siretart)]

The ThinkVantage button is still broken in intrepid as well.

>> uname -a
Linux faui44a 2.6.27-1-generic #1 SMP Sat Aug 23 23:20:09 UTC 2008 i686 GNU/Linux

[ccc1 (cllccl-deactivatedaccount)]

still broken in intrepid and there are a few other problems with thinkpad special keys on my x200:

1) the mute button works, but there is no OSD.
2) pressing the mutebutton again doesn't unmute. one has to press the volume up or volume down key to unmute.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Սահակ (petrosyan)]

This bug has been fixed in Ubuntu 9.04

ThinkVantage key generates XF86Launch1

[Cyril Jaquier (cyril-jaquier)]

I installed Jaunty on my T61 yesterday and I can also confirm that my ThinkVantage key works out-of-the-box and generates a XF86Launch1 event.

[Jouston Huang (jouston-huang)]

On Intrepid this issue reopen again with ThinkPad X200. I need to do "setkeycodes e073 148" to make it expose XF86Launch1 keysym.

[Andy Whitcroft (apw)]

This has been tested and confirmed as fixed in Jaunty and later. Closing the development task Fix Released.

[Andy Whitcroft (apw)]

In the older releases (hardy and intrepid) the underlying issue here is that we can nolonger inject these higher numbered keycodes into the keyboard stream. We would need to convert over to the new event model as supported by later kernels, and to do that we would need back ported drivers which would not be acceptable for SRU to either of these releases.

As by default this key is not actually bound to any action even in Jaunty where this key is correctly mapped the users is already having to configure the system to get this key to do something. As we do have a pretty simple workaround for those affected users on these older releases (the setkeycode workaround above) to make this produce a deliverable key combination it does not seem appropriate to attempt to supply a fix there.