Some ThinkPad hotkeys don't work with evdev

Confirming, happens on my Dell Latitude D430 as well.

If I run xev, I see some activity when I press the sleep key:

MappingNotify event, serial 33, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

which seems to indicate that the event is making it as far as the X server. I think it's gnome-power-manager which is expected to receive the event and act on it, but that isn't happening.

bug 258177 and bug 258964 may be related

I've confirmed that acpi-fakekey is writing the event to /dev/input/event1 ("AT Translated Set 2 keyboard"). I'm not sure how to debug this further; I assume that X is listening for events from that device but can't confirm.

Perhaps this relates to bug 44169, where certain keys (including media keys) get mapped as mouse events under evdev rather than being handled as keyboard events - resulting in the keys not being handled (or perhaps mapping to unexpected functions).

For now, I'm going to dupe the other two to this one; if bug 44169 looks like the correct match, we can dupe all of these to it.

I've debugged this further, and when using kbd instead of evdev for the keyboard, some hotkeys on my Lenovo X61 start working (battery, hibernate..). What I also noticed is that only suspend and lock screen are handled by the default keyboard driver in the kernel, and the rest is up to the "Thinkpad Extra Buttons" device (handled by thinkpad_acpi module).

The reason is that evdev grabs the device, you can see that on the Xorg logfile. This can be easily worked around by installing an fdi file that matches the device and doesn't set the driver (input.x11_driver). But, that's probably not the correct way to fix this. Running evtest on the input device shows all the keycodes (and more), so whatever should listen to them should be fixed.

so the event flow should be like this:

kernel -> X -> gpm -> hal

and not

kernel -> hal -> gpm -> hal

Timo, do you know of something we can do to correct the flow? Or do we need to switch back to kdb instead of evdev?

On a inspiron 1420, I can reproduce the sleep key (Fn+F1) not functioning. evtest shows that evdev is seeing the event code:

    ...
    Event code 125 (LeftMeta)
    Event code 126 (RightMeta)
    Event code 127 (Compose)
    Event code 128 (Stop)
    Event code 140 (Calc)
    Event code 142 (Sleep)
    Event code 143 (WakeUp)
    Event code 155 (Mail)
    Event code 156 (Bookmarks)
    Event code 157 (Computer)
    ...

So it sounds like X is seeing and handling the key fine, but gnome-power-manager isn't evdev aware or something? Is this a GNOME bug rather than an X bug?

Actually no - for Dells Fn+F1 maps to Hibernate, not Sleep. Still doesn't work, though, but perhaps for different reasons.

Fn+F3 (Battery) also does not work, however I can't confirm it ever worked.

All of my other media keys are working correctly (brightness, volume, eject, etc.)

xev shows that Fn+F1 is being mapped correctly:

keycode 213 = (keysym 0x1008ff10, XF86Standby)

/usr/share/X11/XKeysymDB:
XF86Standby :1008FF10

/usr/share/X11/xkb/keycodes/xfree86:
    <I55> = 213;

Launching gnome-keybindings-properties, I found that nothing was being mapped to the Suspend action, and that I could easily associate it by typing Fn+F1, causing XF86Standby to be listed. I tested associating it to 'Launch help browser' and verified that the key handling does indeed work. However, with it mapped to Suspend, I'm still not seeing hibernate or sleep mode be triggered.

Running sudo /etc/acpi/sleepbtn.sh manually does work for me (and locks up the machine on resume). However, I can't find evidence that this script is getting invoked when the button is pressed. mdz where did you see those addon-acpid.c messages?

On Wed, Sep 10, 2008 at 10:01:03PM -0000, Bryce Harrington wrote:
> Running sudo /etc/acpi/sleepbtn.sh manually does work for me (and locks
> up the machine on resume). However, I can't find evidence that this
> script is getting invoked when the button is pressed. mdz where did you
> see those addon-acpid.c messages?

Those were from hald verbose output.

--
 - mdz

On Wed, Sep 10, 2008 at 10:01:03PM -0000, Bryce Harrington wrote:
> Running sudo /etc/acpi/sleepbtn.sh manually does work for me (and locks
> up the machine on resume). However, I can't find evidence that this
> script is getting invoked when the button is pressed. mdz where did you
> see those addon-acpid.c messages?

I don't think /etc/acpi/sleepbtn.sh is relevant here; hal uses the scripts
in /usr/lib/hal instead.

--
 - mdz

Perhaps they were in /proc/acpi/event? But on my system I get an error trying to view it:

$ sudo cat /proc/acpi/event
cat: /proc/acpi/event: Device or resource busy

> Those were from hald verbose output.

Ah. Well, with running hald manually, I still do not see messages from addon-acpi.c when hitting my hibernate button.

> I don't think /etc/acpi/sleepbtn.sh is relevant here; hal uses the scripts in /usr/lib/hal instead.

Perhaps I'm confused - you'd mentioned sleepbtn.sh in the original description?

The suspend script in /usr/lib/hal don't seem to be executable directly, but if I run the following command from it, it sleeps correctly (although keyboard stops working on resume - but that's a different problem).

dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

Near as I can tell, X is propagating the Fn+F1 key for me up as the XF86Standby event, which I can map to suspend in gnome-keybindings-properties. Looking in the gdm source code, this should invoke the SuspendCommand listed in /etc/gdm/gdm.conf, which is specified to be /usr/sbin/pm-suspend. Invoking that manually also seems to work (with the same keyboard issue). I think that is invoking the kernel suspend directly, not going through hal.

Pitti, you mention you reproduced it on a Dell - can you look at the xev output and see if you get something that looks like mdz's output, or something that looks more like mine?

KeyPress event, serial 33, synthetic NO, window 0x3800001,
    root 0x7b, subw 0x0, time 7902503, (870,331), root:(876,404),
    state 0x4, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

<slangasek> jcristau, bryce: re-selecting generic/evdev in gnome-keyboard-properties under 'layouts' is sufficient to recreate the b0rkage
<slangasek> and setxkbmap -rules evdev clears it

According to slangasek, both he and mdz use dvorak keyboards, however slangasek was able to reproduce the issue with the US keyboard layout.

On Thu, Sep 11, 2008 at 01:22:39AM -0000, Bryce Harrington wrote:
> > Those were from hald verbose output.
>
> Ah. Well, with running hald manually, I still do not see messages from
> addon-acpi.c when hitting my hibernate button.

Sometimes these buttons just send normal scancodes, sometimes they're ACPI
events, maybe even other things.

> > I don't think /etc/acpi/sleepbtn.sh is relevant here; hal uses the
> scripts in /usr/lib/hal instead.
>
> Perhaps I'm confused - you'd mentioned sleepbtn.sh in the original
> description?

Sorry, I was confused, I read that as sleep.sh.

If sleepbtn.sh works for you, then that helps to isolate the problem.
What's handling it from there on your system?

> Near as I can tell, X is propagating the Fn+F1 key for me up as the
> XF86Standby event, which I can map to suspend in gnome-keybindings-
> properties. Looking in the gdm source code, this should invoke the
> SuspendCommand listed in /etc/gdm/gdm.conf, which is specified to be
> /usr/sbin/pm-suspend. Invoking that manually also seems to work (with
> the same keyboard issue). I think that is invoking the kernel suspend
> directly, not going through hal.

This should work out of the box, and always has before, without changing
settings in gnome-keybindings-properties.

The default accelerator for Suspend on my system is Disabled. I haven't
checked Hardy.

Usually, my keyboard comes back within a few seconds (though the delay is
long enough that it's confusing when i try to unlock the screen). However,
last night, on one attempt, my keyboard never came back and I had to hard
reset the system. Since you saw that as well, please open a bug about it.

--
 - mdz

the keyboard not waking up -bug is fixed upstream (evdev).

I've done some testing here, and it appears that the keyboard behavior for me is very different between my normal user account upgraded from hardy, and a second test account. Both accounts use dvorak as the keymap. On the non-working account, various media keys are mapped wrong unless I run 'setxkbmap -rules evdev' by hand; both before and after running setxkbmap, these media keys generate KeyPress events according to xev. The KeyPress events are not picked up by the relevant apps, however. On the working test account, there are /no/ KeyPress events generated, but the events that are generated (MappingKeyboard events?) are picked up correctly by the applications - all of the XF86AudioPlay, XF86AudioStop, sleep, and lock keys work correctly.

This is on a Thinkpad T60.

I've only tested this using fast-user-switch-applet, so I haven't confirmed yet whether this is a first session/second session issue or if it' s a difference between the configuration of the two accounts. Continuing to investigate.

Bryce,

for Fn+F1 (Hibernate, Dell D430) I get

KeyPress event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x0, time 330564, (6,65), root:(1102,681),
    state 0x0, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

for Fn+F3 (Battery status) I get

KeyPress event, serial 34, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x0, time 335763, (6,65), root:(1102,681),
    state 0x0, keycode 244 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Those keys do not work any more in intrepid, but worked fine under Hardy. The mute, volume, and screen brightness keys do work and also trigger the gnome-settings-daemon/compiz feedback windows, but don't generate KeyPress xevs. Instead I just get some focus out/in (probably due to the transient g-s-d window) and

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys: 2 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

This is for my existing user account which I have since Hardy.

I did the same in a guest session, i. e. on a completely virgin user account, and get the same key syms, keycodes, and other parameters except of course coordinates and window IDs.

Aha! Pitti, your xev output is not the same as mdz's or slangasek's, since it shows it (correctly) mapped to XF86Standby, which was the case with my Dell as well.

Slangasek says that removing ~/.Xmodmap (or creating a new user) helped make the keys start being recognized (although some still didn't function but for other reasons).

mdz, if you create a new user account and configure the same laptop layout, do you have the same symptoms?

comparing my pre-existing account with my test account, one difference is the presence of a .Xmodmap in my main account, which I was using to map the media keys in hardy. Moving aside my .Xmodmap brings up a correct set of keybindings in the session. So that accounts for that part of the breakage on my side, leaving me with only the Fn+F4 (sleep) and Fn+F12 (hibernate) buttons failing to work.

Some further data. slangasek and I got together downtown to look at his keyboard issue, which is the same thinkpad model as mdz's. His particular symptoms are that the sleep key works one time, and then not after that. Looking into this, we found that at the kernel level, it prints the correct keycode once to /proc/acpi/event, and then nothing after that. Unloading the thinkpad-acpi kernel module and re-modprobing it causes the behavior to reset, with the key printed one time again. The /etc/acpi/sleepbtn.sh script does get called, but the machine does not sleep.

So at this point, I think we're seeing at least two different unrelated bugs - one is this thinkpad-acpi issue (which slangasek and I think is a kernel bug, and I'll file a task against it). I also think this is a Thinkpad-specific kernel bug.

Pitti and I (on Dells) are not seeing this particular bug, but are seeing something different, where the keys are showing up as mapped, but the functionality (sleep, battery, etc.) are not getting triggered. I do not find evidence that /etc/acpi/sleepbtn.sh is getting called.

I'm certain there are also additional bugs beyond this in the acpi/power-management handling code that we're running into. I think we should probably limit the scope of this bug report to the thinkpad-acpi issue. I'll file the dell sleep issue as a new bug.

[Unassigning from timo since it appears to slangasek and I to be a kernel issue rather than X.]

I've broken out the .Xmodmap problem slangasek had run into as bug 269619.

I've broken out the suspend key problem that I ran into as bug 269951. Pitti, I believe that this is the issue you're running into. If you could, please check your symptoms against what I described there and comment either way there. At this stage I don't know if my issue is specific to the 1420N, specific to multiple Dell models, or more widely encountered.

(The keyboard lockup I mentioned I had experienced earlier on resume from sleep is gone. Unfortunately, it appears the network is lost on resume now. I've filed this issue as bug 269956.)

Bryce Harrington [2008-09-13 22:08 -0000]:
> I've broken out the suspend key problem that I ran into as bug 269951.
> Pitti, I believe that this is the issue you're running into. If you
> could, please check your symptoms against what I described there and
> comment either way there

Done. Thanks!

On Fri, Sep 12, 2008 at 09:12:30PM -0000, Bryce Harrington wrote:
> Aha! Pitti, your xev output is not the same as mdz's or slangasek's,
> since it shows it (correctly) mapped to XF86Standby, which was the case
> with my Dell as well.
>
> Slangasek says that removing ~/.Xmodmap (or creating a new user) helped
> make the keys start being recognized (although some still didn't
> function but for other reasons).
>
> mdz, if you create a new user account and configure the same laptop
> layout, do you have the same symptoms?

I tried a guest session, and I was my hotkeys worked as normal there. I
discovered in the process that locking the guest session is probably not a
useful thing to do. :-)

--
 - mdz

On Fri, Sep 12, 2008 at 10:21:55PM -0000, Bryce Harrington wrote:
> Some further data. slangasek and I got together downtown to look at his
> keyboard issue, which is the same thinkpad model as mdz's. His
> particular symptoms are that the sleep key works one time, and then not
> after that. Looking into this, we found that at the kernel level, it
> prints the correct keycode once to /proc/acpi/event, and then nothing
> after that. Unloading the thinkpad-acpi kernel module and re-modprobing
> it causes the behavior to reset, with the key printed one time again.
> The /etc/acpi/sleepbtn.sh script does get called, but the machine does
> not sleep.

This is normal and expected; it won't emit the same ACPI event twice in
rapid succession.

> Pitti and I (on Dells) are not seeing this particular bug, but are
> seeing something different, where the keys are showing up as mapped, but
> the functionality (sleep, battery, etc.) are not getting triggered. I
> do not find evidence that /etc/acpi/sleepbtn.sh is getting called.

This is what I see in my session, though they work in a guest session.

--
 - mdz

On Sat, Sep 13, 2008 at 10:08:05PM -0000, Bryce Harrington wrote:
> (The keyboard lockup I mentioned I had experienced earlier on resume
> from sleep is gone.

My keyboard and mouse still take several (uncomfortable) seconds to come
back after resume. A bug should be opened about this if someone else can
reproduce as well.

--
 - mdz

So if the sleep key problem has been tracked down as far as the last few comments indicate, what happened to the rest of this bug? mdz reported that the following keys don't work:

Fn+F2 (lock screen)
Fn+F3 (battery)
Fn+F4 (sleep)
Fn+F12 (hibernate)

At least Fn-F2 works for me in a guest session, but not in my ordinary session. Same thing with the mute button.

Has something changed in Gnome with regards to keybindings after hardy?

Is this bug the same as the long-standing bug https://bugs.launchpad.net/bugs/217504 ? That one is
caused because the kernel now rejects the fake keypresses from acpi-fakekey if they are beyond KEY_MAX. This is now by design so acpi-fakekey is dead -- it is no longer a viable way to handle these keys and
another way needs to be found. Or have I misunderstood? Please see my post and later ones in that
bug thread.

On my Thinkpad T61, Fn-Home (brightness up) and Fn-End (brightness down) don't work either.

And yes, this seems to be related to bug #217504 as "registername" wrote.

Just to be clear: this is not a kernel bug -- the behaviour was changed deliberately in 2.6.24. Hardy should not have been released using acpi-fakekey in /etc/acpi scripts. And neither should Intrepid.

How can a critical bug be assigned to nobody?

If this is indeed a dupe of the old 217504, could someone verify that the kernel fix mentioned in this comment solves it?

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/217504/comments/58

I do agree in reading that bug, it sounds suspiciously like our culprit. Thanks for pointing to it. If someone can confirm it, we should get the kernel team to incorporate that patch.

registername, thanks for your clarification. So sounds like the acpi scripts need to be modified to not use acpi-fakekey for propagating these events. What should they be using?

@registername, also one question - if the kernel is no longer accepting the fake keypresses, then how is it that the keys appear to work in a guest sessions as described in comment #31, etc.?

Bug 162895 reports a similar issue of hotkeys not working on thinkpads. The reporter said that after removing the thinkpad_acpi module, the laptop would suspend and resume properly.

I confirm that doing a "modprobe -r thinkpad_acpi" makes Suspend (Fn-F4) work again.

Note: other hotkeys still don't work (Fn-F2: lock, Fn-Home: brightness up, Fn-End: brightness down, etc)

OK, seems after a Suspend-Resume cycle, Brightness-Up/Dn now works as well.

Note: Fn-F2(Lock) still does not work, though.

Hm, I still have thinkpad_acpi loaded and now after resume the Fn-F2 (lock) works.

Something's not right in the analysis, here; these are keys that worked fine in hardy, whereas bug #217504 is clearly a bug reported /against/ hardy. Has the KEY_MAX value been changed in later kernels, or why else is this thought to be the same bug?

@Bryce perhaps you should talk to Richard Hughes at freedesktop.org about this. He has some
interesting pages about HAL.

http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-intro.html
http://people.freedesktop.org/~hughsient/quirk/
http://hughsient.livejournal.com/29730.html

@Bryce: I mean talk to Richard Hughes about how to rework the whole special keys situation in Ubuntu.

@Bryce: I'm not sure I understand what people mean by "guest session". It's not just a different user account is it? Why would that make a difference? Unless you're talking about higher level stuff user specific stuff,
rather than the underlying problem.

@Steve for me this was broken in Hardy with a Thinkpad. Perhaps people who reported it working in Hardy
could give more info. Or did they mean Gutsy or earlier?

Important to note also that Thinkpads are different because, as I understand it, they have keys which
need nvram polling in kernel space -- done by the kernel module "thinkpad_acpi".

On Wed, Sep 17, 2008 at 02:11:33PM -0000, registername wrote:
> @Steve for me this was broken in Hardy with a Thinkpad. Perhaps people who
> reported it working in Hardy could give more info.

What info is needed?

> Or did they mean Gutsy or earlier?

No, it has been stated from the beginning of the bug that this is a
regression against hardy!

On Wed, Sep 17, 2008 at 12:00:37AM -0000, registername wrote:
> Just to be clear: this is not a kernel bug -- the behaviour was changed
> deliberately in 2.6.24. Hardy should not have been released using acpi-
> fakekey in /etc/acpi scripts. And neither should Intrepid.

You're talking about a different issue (if it is an issue at all). This
worked fine in 8.04.

--
 - mdz

On my Thinkpad T61, Fn-Home (brightness up) and Fn-End (brightness down) don't work either and the other Fn still doesn't work until now

> > @Steve for me this was broken in Hardy with a Thinkpad. Perhaps people who
> > reported it working in Hardy could give more info.
>What info is needed?

I mean, we know from bug https://bugs.launchpad.net/bugs/217504 that acpi_fakekey has
been broken since 2.6.24 was introduced, i.e. Hardy. So I agree with you there is a contradiction.

So if someone has keys working in Hardy it should be informative to check *why*, i.e. check
whether acpi_fakekey was called and which codes if any were sent by acpi_fakekey and
whether they got through.

Note acpi_fakekey is not 100% broken: codes below KEY_MAX do get through.

You can also look at the scripts in /etc/acpi and look at the codes defined in
/usr/share/acpi-support/key-constants and run acpi_fakekey from the keyboard.

So for me (in Hardy) for example
 sudo acpi_fakekey 10 sends a "9" into my terminal, but
 sudo acpi_fakekey 224
does not lower the brightness, and
 sudo acpi_fakekey 154
does not lock the screen

It's 152 that is lock, not 154. That has started to work for me suddenly both by hitting Fn-F2 and with acpi_fakekey.

Sorry that was a typo from me, I did try 152 for lock.

I spent some time today porting in some changes from Debian to acpi-support:

  http://bryceharrington.org/ubuntu/ACPI/

We seem to be the upstream for this package, yet have not been keeping it up to date with Debian's changes. This update includes a cherrypicked set of fixes that look relevant to us. Please test and provide feedback here:

Tried updated (0.111-pre1) acpi-support, but hotkeys:
Fn+F2 (lock screen)
Fn+F3 (battery)
Fn+F4 (sleep)
Fn+F12 (hibernate)
Brightness Up/Down

on Thinkpad T61 still don't work.

Just a heads up to folks, I'm tracking this down and will report back here when I find something.

@E_rulez, thanks for testing it. There's more that could be pulled in but I'll wait until Ben's had some time to investigate.

On my T61p with acpi-support_0.111-pre1_i386.deb:
Fn+F2 (lock screen) - works
Fn+F3 (battery) - does not work
Fn+F4 (sleep) works
Fn+F12 (hibernate) - does not work
Brightness Up/Down - dims and brightens but no GUI brightness scale support (GUI only appears whe un-/plugging power)

Linux jojo-thinkpad 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux

Just to collect some data here: It would be interesting to know what happens if we entirely remove acpi-support and acpid. Nowadays hal has tons of FDI files for pretty much the same purpose, so at some point those two should just disappear completely. It works fine on my Dell Latitude.

For trying:

  sudo dpkg -P --force-depends acpid acpi-support powermanagement-interface

then reboot, and check whether the power button, sleep key, etc. behave any different.

For reverting:

  sudo apt-get -f install

Thanks!

(For the record, I'm not proposing to do that for Intrepid, it's way too late for that, but to get some more debugging for this particular problem).

@Martin Pitt
tired what you suggested, but after reboot none of these keys work:
Fn+F2, Fn+F3, Fn+F4, Fn+F5, Fn+F12, BrightnessUp/Down

but i guess it wasn't unexpected, as my Thinkpad is custom made [T61 (7659-Y7H)] so it is very unlikely
that it is added to any FDI file.

tried Ubuntu 8.10 alpha 6 LiveCD:
hotkeys Fn+F2 (lock), Fn+F4 (sleep), Brightness Up/Down
work there.

What is interesting, is that
if I log in/switch to a newly created user, same hotkeys
work there. Using acpi-support_0.110 (same happens when
using acpi-support_0.111-pre1).

What could prevent me from using these keys while using my
regular user?

@jojo, thanks for testing, however what we need to know is how behaviors changed - does 111 work the same, better, or worse than 109?

I confirm that if I log to the "guest" user, Fn-F2(lock) and Brightness-up/down work, but sleep (Fn-F4) does not work.

well comparing with acpi-support 0.110 (not 109), 111-pre1 changes nothing

Situation on Thinkpad R61i, Kubuntu, Intrepid alpha 6

Fn+F2 (should lock the screen): does nothing
Fn+F3 (battery state): does nothing
Fn+F4 (should suspend to RAM) : does nothing [worked fine in Hardy]
Fn+F5 (should toggle wireless connections): seems to toggle bluetooth, does not toggle wifi
Fn+F7 (should toggle the video output): probably does nothing
Fn+F12 (should suspend to disk): does suspend to RAM [worked fine in hardy]
Fn+PgUp (should swith on/off the external light): works fine
Fn+Home / Fn+End (should change the brightness of the screen): changes the brightness of the screen after one second delay

On my T42 (2379-R5U):

Fn-F4 (suspend to RAM) and Fn-12 (hibernate) started working as a result of removing the packages Martin Pitt mentioned. The power button and lock screen combo (Fn-F3) were working beforehand (and still do).

Fn-F5 (wireless toggle) doesn't seem to be working anymore (doesn't toggle bluetooth or wifi)

The "Access IBM", zoom (Fn-Space), and mute buttons still don't work.

Fn-Home. Fn-End (brightness up/down) worked before, but still don't display the brightness popup.

Removing the packages also seemed to fix a small bug I had where Fn-F2 registered the same event as Fn-F3 (it shouldn't do anything).

When some people reported some of the hotkeys working as guest user, I decided to try to delete my home directory, logout and log back in, and suddenly, some of the hotkeys work again.

- Fn-F2(Lock): does NOT work
- Fn-F3(Battery): does NOT work
- Fn-F4 (Suspend): works
- Fn-Home/Fn-End (brightness up/down): works

Correction: Fn-F2 (Lock) works from a clean home directory.

I was able to identify that "~/.gconf" or "~/.gconfd" directories were responsible for this. Once they were removed, from my home directory, the hotkeys started working again.

Hope this helps someone.

On 23.09.2008 19:16 Marc Jauvin wrote:
> I was able to identify that "~/.gconf" or "~/.gconfd" directories were
> responsible for this.
This is wrong as your home or /etc/ directory is reponsible for this.
The GConf directories contain configuration information for your
applications. You should rather try to identify the keys which are set
to a "wrong" value.
> Once they were removed, from my home directory,
> the hotkeys started working again.
>
> Hope this helps someone.
>
Please don't follow this advice as it deletes pretty much all of your
configuration data, i.e. Panel or Evolution settings.

I prefer to lose those settings and get back the hotkeys. It's a matter of minutes to redo those settings anyway. If someone wants to have fun with those keys, go ahead, at least we know a little bit more where to search.

Here's the fdi file to disable evdev from grabbing the device:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <match key="info.product" contains="ThinkPad Extra Buttons">
        <merge key="input.x11_driver" type="string"></merge>
      </match>
    </match>
  </device>
</deviceinfo>

put it in for instance /etc/hal/fdi/policy/thinkpad.fdi and restart hal & X. Now the battery & hibernate buttons work. Events are then sent directly to hald? Also, for the radio-button to work I need to have acpid running.

With the above hack the battery key generates keycode 241 and not 244 like with evdev..

I'm happy to report that Timo's proposed /etc/hal/fdi/policy/thinkpad.fdi file works on my system as well, restoring Fn-F{2,3,12} to working order under my normal account. Fn-F4 (sleep) does not appear to work - so the delta here for me is that Fn-F12 (hibernate) has started working.

Fn-F4 continues to be problematic, both in that it doesn't reliably generate events (why is the sleep key the only one that has some sort of mandatory delay between events when you press it? how long is the timeout, to confirm that this is really the issue?), and that nothing appears to act on the events. Interestingly, there's a different ACPI event depending on whether the thinkpad_acpi module is loaded: ibm/hotkey HKEY 00000080 00001004 vs. button/sleep SLPB 00000080 00000001, and neither appears to be recognized by hal.

Matt does this match the behavior you see if you use the above thinkpad.fdi?

Timo, if this takes care of the issue, is this an appropriate fix for the problem, that can be included in hal?

The Fn+F7 button (video output) is also still not recognized for me by hal, but I don't know if that's related to this bug.

Martin, at this point this behavior is also consistent with or without acpid running (though I didn't uninstall it, here).

For me Timo's proposed /etc/hal/fdi/policy/thinkpad.fdi restores
Fn-F{2,3,4,12}, however, brightness Up/Down still don't work in my user account.

@Steve Langasek:
Sleep and Hibernate keys both have the delay (60 s or so), it is normal, I remember
reading it on some Thinkpad R50 documentation a while ago.

On my T60 Timos proposed thinkpad.fdi made Fn-F 2,3,4 and 12 working again.
Brightness Up/Down never stopped working.

I don't have any delay after hitting the sleep or hibernate keys.

Steve: I think it's a valid workaround at least for Intrepid unless a proper fix is found in time.

On Thu, Sep 25, 2008 at 01:45:42AM -0000, Steve Langasek wrote:
> Matt does this match the behavior you see if you use the above
> thinkpad.fdi?

Before adding FDI:
Fn+F2 (lock screen): doesn't work
Fn+F3 (battery): doesn't work
Fn+F4 (suspend): doesn't work
Fn+F5 (RF kill): works
Fn+F7 (detect screens): works
Fn+F12 (hibernate): doesn't work
Fn+Home (brightness up): doesn't work
Fn+End (brightness down): doesn't work

After adding FDI:
Fn+F2 (lock screen): works
Fn+F3 (battery): works
Fn+F4 (suspend): works
Fn+F5 (RF kill): works
Fn+F7 (detect screens): doesn't work
Fn+F12 (hibernate): works
Fn+Home (brightness up): doesn't work
Fn+End (brightness down): doesn't work

To summarize, adding the FDI fixed lock screen, battery, suspend and hibernate,
had no effect on brightness up/down, and seemed to break detect screens.

--
 - mdz

Timo, why don't you commit this workaround for Intrepid?

Here is some info about the Fn-F4 sleep button and ACPI, see message 34:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467374#34

Matt, could you post your lshal output to this bug (if you haven't already - I couldn't see it)?

Over the weekend, I will:

- Look at a ThinkPad running 8.04 and figure out which path the hotkeys used to take
- Try to get the same setup working on another ThinkPad running Intrepid
- Send lshal output from both systems

I have a Thinkpad X61 running Hardy, and a Thinkpad T61p running
Intrepid. I'm posting the lshal data from each.

I can confirm that the Suspend button (fn+F4) works on Hardy, but does
not work on Intrepid. I can also confirm that `sudo acpi_fakekey 142`
works on Hardy, but does not work on Intrepid.

:-Dustin

With some help from Dustin Kirkland and Julien Cristau on IRC, I have a working theory for what's causing this:

Hardy: kernel acpi event -> acpid -> /etc/acpi/*btn.sh -> acpi_fakekey -> /dev/input/eventX -> hald-addon-input -> hald

Intrepid: kernel acpi event -> acpid -> /etc/acpi/*btn.sh -> acpi_fakekey -> /dev/input/eventX -> X server -> *splat*

It seems that the X server grabs the relevant /dev/input/eventX with ioctl(EVIOCGRAB), which means it gets exclusive access to the events, so hald-addon-input never hears them.

Probably what we want in the end is:

kernel acpi event -> hald-addon-acpi -> hald

but that won't fly for Intrepid as it would require ripping and replacing acpi-support with hal FDI files.

For Intrepid, we could try to get this working:

kernel acpi event -> acpid -> hald-addon-acpi -> hald

I believe hald-addon-acpi has native support for the weird thinkpad ACPI events.

OR, we could try to make the input events work somehow. If X insists on exclusive access, something in the session would need to listen for them.

Assuming these events are going via the "ThinkPad Extra Buttons" device, Timo's FDI file seems like a reasonable way to get the current setup working for Intrepid. I'm attaching it here to avoid digging through the comments for it again.

There seem to be two outstanding issues though:
- Some folks with non-ThinkPad laptops are having problems (need to file a separate bug)
- The brightness keys still don't work (needs some analysis, but potentially a separate bug as well)

Found out how to fix Brightness Up/Down keys in my account based on Marc's idea:
1. rm -rf .gconf/desktop/gnome/peripherals/keyboard/host-`hostname`
2. Set System->Preferences->Keyboard->Keyboard model = Evdev-managed keyboard
3. edit ~/.Xmodmap and remove keycodes 233/234 (if there are any definitions). These
keycodes in Hardy were sent by Back/Forward keys above Left/Right Arrow keys, but now
these keys have keycodes 166/167 and are already correctly mapped to XF86Back/XF86Forward,
so no need to remap them in .Xmodmap.
4. Restart X.

Thanks Aurimas,

This worked for brightness on my X61s, too. This workaround also brought back FN+F2 (locking the screen).

Thx Peter

Thx @ Matt for the fdi File.

With these two workaround I can use all the functionality I used in hardy. Thanks again.

fwiw, brightness keys here have been working for me all along - but they aren't generating ACPI events (nor are the volume up/down keys), and nothing in GNOME handles them; they appear to be acting at the hardware level. This is suboptimal, but at least in the case of the brightness keys it's not a regression for me from hardy. (The volume up/down *is* a regression - whatever volume control these buttons are now controlling, it's one that I can't see at all from software...)

Anyway, at this point I think that a separate bug report is warranted for the remaining issues (Fn+F7, brightness up/down?)

I was asked to upload this fdi file, so that we have a workaround for intrepid, in time for beta.

I'll ship it in -input-evdev to do the right thing wrt. backports to hardy.

Whoops, right. hal already ships the fdi for enabling input hotplug in the first place, so backports of hal will be broken either way. Let's keep it in hal then.

This bug was fixed in the package hal - 0.5.11-3~ubuntu9

---------------
hal (0.5.11-3~ubuntu9) intrepid; urgency=low

  * debian/10-x11-keymap.fdi: Disable -evdev for the ThinkPad extra buttons;
    -evdev currently exclusively grabs that input device without properly
    passing it on. This workaround restores the old path through acpid and
    hal. (LP: #267682)

 -- Martin Pitt <email address hidden> Mon, 29 Sep 2008 14:58:51 +0200

Closing the acpi-support task since fixed in hal. (For Jaunty we'll probably focus on getting acpi-support out of involvement for this anyway.)

Yes, Aurimas's workaround for brightness keys works on my Thinkpad r61i, however changing of brightness is really slow compared to it in Hardy (about 1 unit per second), so this problem seems to be relevant...

I've opened bug 280646 about the brightness issue, since it seems to be separate.

Sorry for breaking the party, but the problem remains in Kubuntu (under GNOME all keys work fine).
Kubuntu 8.10 beta with all upgrades,
Thinkpad R61i.

On Fri, Oct 10, 2008 at 06:44:39AM -0000, Katsudon wrote:
> Sorry for breaking the party, but the problem remains in Kubuntu (under GNOME all keys work fine).
> Kubuntu 8.10 beta with all upgrades,
> Thinkpad R61i.

Please file a separate bug about that.

--
 - mdz

I have a Inspirin 1420 and the problem it's not fully fixed for me...

some the buttons now work (multimedia keys), but I have to keep them pressed for about 1~2 seconds or else they dont work

i have instaled the latest update to the hal package (0.5.11-4ubuntu2)

I still can't use FN+ESC (hibernate), FN+F3 (Battery status), FN+F8 (CRT/LCD) or FN+F10 (EJECT), which worked fine in hardy

On Sat, Oct 11, 2008 at 04:35:24PM -0000, Angelo Bernardi wrote:
> I have a Inspirin 1420 and the problem it's not fully fixed for me...
>
> some the buttons now work (multimedia keys), but I have to keep them
> pressed for about 1~2 seconds or else they dont work
>
> i have instaled the latest update to the hal package (0.5.11-4ubuntu2)
>
> I still can't use FN+ESC (hibernate), FN+F3 (Battery status), FN+F8
> (CRT/LCD) or FN+F10 (EJECT), which worked fine in hardy

This issue was specific to ThinkPads. You must have a different problem,
and should file it as a separate bug.

--
 - mdz

i can confirm it also on my ibm thinkpad x40

only Fn+F5 owrking (turning on and off bluetooth and wifi)

I can confirm this problem. IT appears to be a kernel issue. The fn keys for brightness, bluetooth and wifi work fine for me. fn-f4 (suspend) will only work if I do "modprobe -r thinkpad_acpi" as noted above. The issue also occurs if I switch to a console, so it would appear to be some kind of acpi/kernel problem rather than with xorg event handling.

I guess this is a KDE4 issue for me - fixed it by installing kpowersave. The process gets as far as acpid running 'fake_acpi 142', which opens /dev/input/event1 and writes some data to it. Somewhere the event is being silently dropped between Xorg and KDE4.

With kpowersave running, I can suspend, resume, suspend repeatedly. The ibm_acpi module no longer reports only one keypress (I expect it has some code waiting for resume, since in normal use it shouldn't see two suspends in a row without an intermediate resume).

If this bug is specific to Gnome I'll follow up to https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/281284

When X isn't running the suspend event gets dropped by hald (addon-acpi.c :195: event is ibm/hotkey HKEY 00000080 00001004). I'm not even sure if the suspend button is supposed to work from the console.

Similar regression with 8.04. Are these related via the same kernel issue?

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/125881
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/217504

I'm having the same issue with my IBM/Lenovo T60p laptop.

Fn+F2 (lock) not working
Fn+F3 (bat) not working
Fn+F4 (sleep) not working, works with kscreensave runing
Fn+F5 (wifi) works

Brigthness buttons work but don't show the GUI
vol up and down are working with gui
vol mute mutes the sound but also increases the volume

Kubuntu Intrepid AMD64

I concur with Christian, et al. This defect is *NOT* fixed, and should *NOT* be falsely marked as Fix Released.

On Wed, Dec 10, 2008 at 03:48:44PM -0000, Noel J. Bergman wrote:
> I concur with Christian, et al. This defect is *NOT* fixed, and should
> *NOT* be falsely marked as Fix Released.

The original problem, which I reported and analyzed, has been fixed. If you
are having a problem with your hotkeys, it is a different one, and you
should file a different bug. This report is not about ALL hotkey problems,
but only about a specific one.

I've updated the description to be more specific, in hopes of avoiding
further confusion.

If you need help troubleshooting your hotkeys, please read:

https://wiki.ubuntu.com/Hotkeys/Troubleshooting

--
 - mdz

There are a whole bunch of bugs related to Thinkpad hotkeys at the moment - I don't know if they all stem from the same ultimate issue. It is possible that these represent symptoms of the same bugs or multiple independent bugs, some old bugs that have been fixed but re-appeared recently, and that some of them are new reports and have been fixed but people are latching on to the wrong bug reports since they seem related.

bug #51537 Wrong handling of volume buttons on IBM Thinkpad notebooks
bug #198197 IBM Thinkpad (T23): no OSD indication for volume control display inhibit or thinklight - (original report for Hardy, but comments indicate still present in Intrepid)
bug #198214 thinkpad sleep suspend fn buttons do not work without g-p-m
bug #217504 acpi_fakekey stopped working for certain keycodes
bug #267682 Hotkeys no longer working in Intrepid on Thinkpads
bug #281284 No function keys for sleep and hibernation in Kubuntu on Thinkpad
bug #294400 Intrepid: XF86AudioStop button incorrectly mapped as XF86AudioLowerVolume

I don't know if this is related, but ever since Hardy (and still in Intrepid), my Keyboard Shortcuts Ctrl-Alt-L (Lock screen), Ctrl-Alt-H (Home folder) and Ctrl-Alt-S (Suspend) have stopped working. They're still listed in System -> Preferences -> Keyboard Shortcuts. I don't know how to tell whether this causes acpi events, or whether hal notices them, or whatever, but I can upload any files or log outputs that people might want.

I'm using a Dell Inspiron E1505.

On Sun, Dec 14, 2008 at 08:28:56PM -0000, Toby Bartels wrote:
> I don't know if this is related, but ever since Hardy (and still in
> Intrepid), my Keyboard Shortcuts Ctrl-Alt-L (Lock screen), Ctrl-Alt-H
> (Home folder) and Ctrl-Alt-S (Suspend) have stopped working. They're
> still listed in System -> Preferences -> Keyboard Shortcuts. I don't
> know how to tell whether this causes acpi events, or whether hal notices
> them, or whatever, but I can upload any files or log outputs that people
> might want.

Keyboard shortcuts are not hotkeys. Please file a separate bug for your
issue; gnome-control-center, which provides gnome-keybinding-properties,
might be a good starting point.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thanks, Steve, it looks like my bug is Bug #217685. [unsubscribing]

Hi,

When I updated a few weeks ago from Hardy to intrepid, toggling video output with Fn-f7 stopped working for me.

Only Fn-F7 is broken, other Fn combinations work fine.

HW: IBM thinkpad X40

On Sat, Dec 20, 2008 at 04:12:57PM -0000, Koopee wrote:

> When I updated a few weeks ago from Hardy to intrepid, toggling video
> output with Fn-f7 stopped working for me.

> Only Fn-F7 is broken, other Fn combinations work fine.

Known issue, resolved in jaunty.

The problem is that X won't share the thinkpad hotkey "input device" with
hal in the intrepid version, so X is told not to use it at all, and that
prevents X from seeing this particular key event - which is the only one
that should be handled through X directly instead of through the hal layer.

I don't think we'll be able to provide a good fix for that in intrepid.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thanks Steve for the info!

Well, just wait for the stable jaunty then. The problem was bugging me for quite a time with my dual-head laptop setup. I could not bring the menu bar to the laptop LCD upon disconnecting the external monitor

However, just found a solution: use terminal and launch "gnome-display-properties"... Now I'm capable of cloning the screen after removing external monitor. :)

I have tested Jaunty Kubuntu alpha 3 live CD and Jaunty with updates as of 20080130. Test PC is Thinkpad T42p with dock, external monitor, wifi. Boot live CD and install on a fresh partition (so no homedir/upgrade issues).

fn-f4 does nothing. Should suspend to RAM. Filed bug #323432 but possibly just bug #281284
fn-f5 turns off bluetooth but not wifi. Should toggle both or cycle through combinations. Filed bug #323428
fn-f7 does nothing. Should toggle output video as in http://www.thinkwiki.org/wiki/Sample_Fn-F7_script Filed bug #323433
fn-f12 does nothing. Should hibernate to disk. Possibly bug #281284

I'm just posting this here since it seems suspicious that so many keys are still broken in Jaunty; there may be a common cause related to this bug.

Can anyone confirm that these keys work for sure under a Jaunty Gnome alpha 3 install?

On Sat, Jan 31, 2009 at 01:14:31AM -0000, Chris Bainbridge wrote:
> I have tested Jaunty Kubuntu alpha 3 live CD and Jaunty with updates as
> of 20080130. Test PC is Thinkpad T42p with dock, external monitor, wifi.
> Boot live CD and install on a fresh partition (so no homedir/upgrade
> issues).

> fn-f4 does nothing. Should suspend to RAM. Filed bug #323432 but possibly just bug #281284
> fn-f5 turns off bluetooth but not wifi. Should toggle both or cycle through combinations. Filed bug #323428
> fn-f7 does nothing. Should toggle output video as in http://www.thinkwiki.org/wiki/Sample_Fn-F7_script Filed bug #323433
> fn-f12 does nothing. Should hibernate to disk. Possibly bug #281284

> I'm just posting this here since it seems suspicious that so many keys
> are still broken in Jaunty; there may be a common cause related to this
> bug.

> Can anyone confirm that these keys work for sure under a Jaunty Gnome
> alpha 3 install?

All of Fn+F4, Fn+F5, and Fn+F7 work for me just fine on jaunty on a T60. I
haven't tested Fn+F12 because I don't have resume from suspend-to-disk
configured correctly here.

Please follow <https://wiki.ubuntu.com/Hotkeys/Troubleshooting> to find out
why your keys are not working correctly.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve, you're right, I just tried the Gnome Jaunty alpha 3 live CD and it responds to the keys.

Testing from Gnome Jaunty alpha 3 live CD:

volume and mute keys: no OSD. OSD for brightness keys is ok.
fn-f4: suspends, but on resume suspends again immediately (!), on resume suspends again immediately. Third resume is ok. Selecting suspend from the shutdown menu works ok, so this is some problem specifically related to using fn-f4.
fn-f7: crashes gnome settings daemon. Error in log "gnome-settings .. segfault at ... error 4 in libxrandr.so"
fn-f12: brings up message that hibernate is disabled, presumably because not everyone has a swap partition

I haven't done a full install+upgrade, so it's possible these bugs have since been fixed. I will check if I have time, if not I will re-try with the Jaunty alpha 4 live CD.

btw, I didn't need to configure resume from hibernate in Ubuntu - it worked out of the box. AFAIK you only need a swap partition.

The fact that fn-f4 and fn-f12 aren't recognised in KDE seems to be Kubuntu specific. Probably bug #281284 - no power management installed.

I've experienced the "suspends, but on resume suspends again immediately (!)" problem (even with intrepid).

I've noticed that if I disable screen locking after suspend/resume, it will cause this.
(that's why it's easily reproduceable on a LIVE-CD, because it won't lock the screen on resume)

If it's locking the screen on resume, it won't do this.

I'm using a Thinkpad T61 and I don't recall seeing this in releases prior to Intrepid Ibex.

Should I open a new bug report for this?

> I've experienced the "suspends, but on resume suspends again immediately (!)"
> problem (even with intrepid).

> Should I open a new bug report for this?

See Bug 306310.

Is fn-space (zoom hotkey) supposed to work in Ubuntu? I filed bug #324814 but I'm not seeing any keypress events from xev.

On Tue, Feb 03, 2009 at 12:38:08PM -0000, Chris Bainbridge wrote:
> Is fn-space (zoom hotkey) supposed to work in Ubuntu? I filed bug
> #324814 but I'm not seeing any keypress events from xev.

It won't generate an X key event because the keycode it maps to (KEY_ZOOM)
is outside the 0-255 range supported by X. There is an open bug upstream
about this at <https://bugs.freedesktop.org/show_bug.cgi?id=11227>.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>