[hardy][regression] "Access IBM"/"ThinkVantage" keys not working (KEY_PROG1 ignored by X)

Bug #199502 reported by Chris Jones
8
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Invalid
Medium
Daniel Hahler

Bug Description

Binary package hint: acpi-support

My thinkpad X40 has a blue "Access IBM" button above the keyboard which in previous Ubuntu releases I mapped to Lock Screen.
In hardy, the key event is not being detected by GNOME's Keyboard Shortcut preferences capplet.

acpid sees it:

[Fri Mar 7 15:39:13 2008] received event "ibm/hotkey HKEY 00000080 00001018"
[Fri Mar 7 15:39:13 2008] notifying client 11989[0:0]
[Fri Mar 7 15:39:13 2008] notifying client 17907[110:122]
[Fri Mar 7 15:39:13 2008] executing action "/etc/acpi/thinkpad-thinkpad.sh"
[Fri Mar 7 15:39:13 2008] BEGIN HANDLER MESSAGES
[Fri Mar 7 15:39:13 2008] END HANDLER MESSAGES
[Fri Mar 7 15:39:13 2008] action exited with status 0
[Fri Mar 7 15:39:13 2008] completed event "ibm/hotkey HKEY 00000080 00001018"

So, acpid does basically this in this event:
sudo acpi_fakekey 148

REPRODUCE:
1. start "xev" (from x11-utils) in a shell/terminal
2. arrange the xev window and terminal so that you can see events from xev in the shell window
3. in another shell execute "sleep 10; sudo acpi_fakekey 148"
4. Move the mouse cursor/focus in the xev window
5. Check if a KeyPress and KeyRelease gets displayed when the acpi_fakekey gets executed

Revision history for this message
Chris Jones (cmsj) wrote :

FWIW, the exact same behaviour can be seen with the blue ThinkVantage button on a Thinkpad X300 running hardy.

Revision history for this message
Chris Jones (cmsj) wrote :

Since I can reproduce this on two thinkpads I think it's worth confirming. I've also had it reproduced by an X61s user.

Changed in acpi-support:
status: New → Confirmed
Revision history for this message
Liken Otsoa (liken) wrote : Re: [hardy][regression] "Access IBM"/"ThinkVantage" keys not working

Same problem in IBM Thinkpad X41, Hardy uptodate, Access IBM Blue Button is not detected. In Gutsy it was working.

Revision history for this message
Dominik Possner (dpossner) wrote :

Also in Thinkpad R52, Hardy uptodate (18. 3. 08). The button is not detected by xev.

Revision history for this message
Daniel Hahler (blueyed) wrote :

Has this regressed with acpi-support 0.106?
Please test it using acpi-support 0.105, which you can get from https://edge.launchpad.net/ubuntu/hardy/+source/acpi-support/0.105

Changed in acpi-support:
assignee: nobody → blueyed
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Chris Jones (cmsj) wrote :

I think it's older than that, 0.105 was published 5 days after this bug was filed.

Changed in acpi-support:
status: Incomplete → Confirmed
Revision history for this message
Chris Jones (cmsj) wrote :

I'm not even sure it's acpi-support. calling acpi_fakekey manually for that code does nothing. maybe something changed in X's keyboard bits?

Daniel Hahler (blueyed)
Changed in acpi-support:
assignee: blueyed → nobody
Revision history for this message
aneiser (andreas-neiser) wrote :

Yes, I can confirm that bug, too (ThinkPad R51, Hardy up-to-date). But is it connected to acpi-support?
acpi_listen shows some output when I press the Access IBM Button here:

andi@work03-an:~$ acpi_listen
ibm/hotkey HKEY 00000080 00001018
ibm/hotkey HKEY 00000080 00001018
ibm/hotkey HKEY 00000080 00001018
ibm/hotkey HKEY 00000080 00001018

But xev is silent, though.
I did not test it in gutsy.

Daniel Hahler (blueyed)
description: updated
Revision history for this message
Daniel Hahler (blueyed) wrote :

While "xev" in Gutsy displays an event for "sudo acpi_fakekey 148", in Hardy no event gets displayed.
Therefore I'm assigning the bug to xserver-xorg: I don't know if this is correct, but I think it's nearer to the root cause.

description: updated
Revision history for this message
wes (ttdlx1989) wrote :

Bug is actually in the kernel.
acpi-support is a collection of scripts, acpi-fakekey works in 2.6.22
I also ran Xorg7.4/1.3 on 2.6.22, fakekey still works.

It's only when changing to 2.6.24 does it break. I don't think the problem is X ignoring the event, but the kernel actually dropping the fake input. Looking at the source, there aren't any X components linked in.

Revision history for this message
Daniel Hahler (blueyed) wrote :

Thank you for your investigations, Joey. I've created a new bug 217504 and will make related ones as duplicate of it.

Changed in xorg:
assignee: nobody → blueyed
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.