T61 acpid does not get volume key events after BIOS update

[aseem]

Hi All.

I have a T-61 that I run a stripped down version of ubuntu on. Basically its a CLI install with Openbox + Slim DM. As a result I don't have Gnome/KDE/XFCE stuff on it at all.

Some details about the hardware:
$ cat /var/lib/acpi-support/*-*
7LETB9WW (2.19 )
LENOVO
8897CTO
ThinkPad T61

$ sudo dmidecode | less
BIOS Information
Vendor: LENOVO
Version: 7LETB9WW (2.19 )
Release Date: 06/06/2008
<snip>...</snip>
BIOS Revision: 2.25
Firmware Revision: 1.8

Before the BIOS update (I had not updated it since I had bought the thinkpad) everything worked. Suspend/Hibernate only worked via pm-utils, acpi based suspend/hibernate got me a green (literally) screen and a crashed X.

After the BIOS updated the volume keys do not seem to trigger an acpi event at all. Even xev does not seem to be able to get a keycode:

$ xev
FocusIn event, serial 32, synthetic NO, window 0x1200001,
mode NotifyUngrab, detail NotifyAncestor

FocusOut event, serial 32, synthetic NO, window 0x1200001,
mode NotifyNormal, detail NotifyNonlinear

KeymapNotify event, serial 32, synthetic NO, window 0x0,
keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

acpi_listen shows nothing at all.

I can however use the keys by registering the key-codes in my ~/.Xmodmap to XF86Audio.... variables and then using xbindkeys to manipulate the Master or PCM levels.

The difference is that previously if I did not do anything it would trigger an acpi event which would then execute /etc/acpi/vol[up|down]btn.sh which appeared to modify the /proc/acpi/ibm/volume. I am not quite sure what happened in this update to cause this issue.

I was wondering if anybody else ran into this? I have not tried to install gnome to see if this 'issue' goes away. I also tried downgrading to 2.18-1.08 (unfortunately I have no idea what came version was on it originally) and that did not seem to help either. Does anybody have any idea as to what happened with this update? Are there any workarounds?

Thanks.

[tarvoke]

that xev seems to see nothing is rather weird. do the presses show up in dmesg? I never bother configuring those buttons but still see the acpi events in the system log whenever I bump a key by accident.

did you reset bios settings to defaults after updating it? annoying to have to do that and then pick and choose the non-default stuff you had before, but it seems necessary.

have you tried booting a livecd of the latest ubuntu or kubuntu (or some other slack/fedora/etc.) and see what happens in those?

[aseem]

Well xev does show 'something' unfortunately even after much google-hunting I have not been able to comprehend what the output means.

In ubuntu the acpi events seem to go to /var/log/acpid and all the other keys seem to show up there in the form:

[Sun Aug 3 22:19:53 2008] received event "ibm/hotkey HKEY 00000080 00001018"
[Sun Aug 3 22:19:53 2008] notifying client 4877[106:115]
[Sun Aug 3 22:19:53 2008] notifying client 4958[0:0]
[Sun Aug 3 22:19:53 2008] notifying client 5043[0:0]
[Sun Aug 3 22:19:53 2008] notifying client 5172[1000:1000]
[Sun Aug 3 22:19:53 2008] client has disconnected
[Sun Aug 3 22:19:53 2008] executing action "/etc/acpi/thinkpad-thinkpad.sh"
[Sun Aug 3 22:19:53 2008] BEGIN HANDLER MESSAGES
[Sun Aug 3 22:19:53 2008] END HANDLER MESSAGES

Unfortunately the volume keys do not seem to register anything - most likely because of whatever causes acpi_listen to not get the events.

I did look at the BIOS settings, there were some new ones and some old ones had gone away (1 beaut - the modem was no longer there - no modem no audio ) but all my remaining settings were as I had left them. I reset them back to default hoping that would fix things, but that does not seem to help either.

The keys do raise key events simply not with acpid. That is what boggles the mind. I am able to trap them to munge with alsamixer settings to manipulate mixer volume levels, however the nice part of acpi is that it can modify /proc/acpi/ibm/volume directly, which I would really like to have. For now I have to set the volume to the highest level in /etc/rc.local and then use the mixer to change volume levels - which is not a bad deal simply that if I had acpid I could use the buttons for the hardware device and a mixer app for the mixer.

Thanks.
AM

PS. I have suspend/hibernate working perfectly on ubuntu on T61 if somebody is searching.

[lightweight]

Already tried a newer acpid?

I am able to trap them to munge with alsamixer settings to manipulate mixer volume levels, however the nice part of acpi is that it can modify /proc/acpi/ibm/volume directly, which I would really like to have. For now I have to set the volume to the highest level in /etc/rc.local and then use the mixer to change volume levels - which is not a bad deal simply that if I had acpid I could use the buttons for the hardware device and a mixer app for the mixer.

If that's really all you want and don't mind the hackary, why not have xbindkeys call a script to adjust ibm/volume directly? You don't need acpi's server/socket structure if you, say, have it run as a user who can call the following a quick script or something in BASH/whatever:

Code: Select all

#!/usr/bin/perl -w
use strict;

die "usage: $0 <up|down|mute>" unless (@ARGV > 0);
my $opt=$ARGV[0];
my $file='/proc/acpi/ibm/volume';
# dirty
my $vol=`grep level: $file`;
chomp ($vol,$opt);

#regex for volume level
$vol=~/(\d+)/;
$vol=$1;

#add user to tee from if wanted
if ($opt=~/up/)
	{ $vol++; system("echo \"level $vol\" |tee $file"); }
elsif ($opt=~/down/)
	{ $vol--; system("echo \"level $vol\" |tee $file"); }
elsif ($opt=~/mute/)
	{ system("echo mute |tee $file"); }
else
	{ die "not a valid option.  use up, down, or mute."; }

If you called it and chmod'd +x vol.pl, you could adjust volume with ./vol.pl up, vol.pl down, or vol.pl mute.

Another option is to edit /usr/share/acpi-support/key-constants and map new keys to volume, or ensure that the keymap for existing volume keys have not changed. Let me know if you want my x60s or x61s's file. I'm sure others will post t61 if wanted but should be the same.

FWIW, 2.22 bios here with volume buttons and hibernate working "out of the box" in Debian (after apt-get hibernate ). Thanks for the heads up on 2.5. Interesting problem.

[aseem]

If that's really all you want and don't mind the hackary, why not have xbindkeys call a script to adjust ibm/volume directly? You don't need acpi's server/socket structure if you, say, have it run as a user who can call the following a quick script or something in BASH/whatever:

I am using xbindkeys for the alsamixer manipulation and could do emit levels to the ibm/volume but then the script would have need a +s which I am not a fan of.

Another option is to edit /usr/share/acpi-support/key-constants and map new keys to volume, or ensure that the keymap for existing volume keys have not changed. Let me know if you want my x60s or x61s's file. I'm sure others will post t61 if wanted but should be the same.

The default keymap has the keys associated with the volume keys registered. It's simply that for some bizarre reason the event does not seem to get to acpid. Advogato has a nice overview of the whole ACPI workflow:
http://www.advogato.org/article/913.html
It appears that for some reason the hardware event is not being triggered in the traditional way - which points to the BIOS being the most likely culprit, which is a pain because Lenovo does not 'officially' support linux installs.

The suspend hibernate issue has to do with running ubuntu without gnome/kde/xfce and somebody deciding that s2ram is obsolete and another busybody not making powersaved dependent on uswsusp My entire weekend - gone - forever.

I will try out mapping new keys to vol and see if that gets triggered.

Thanks.
AM

[lightweight]

I am using xbindkeys for the alsamixer manipulation and could do emit levels to the ibm/volume but then the script would have need a +s which I am not a fan of.

Actually, this is incorrect. You don't have to set the +s bit. xbindkeys / ~/.xbindkeysrc will execute as your user. You could chmod /proc/acpi/ibm/volume writeable by your user, or add some group and some user to control these options then adjust the script as necessary (note the tee's you can call as a user if wanted).

Looking at that couple minute script I see I should have just opened a file handler to $file, btw. Let me know if you want a nicer one.

Thanks for the acpi link! Interesting and informative read.