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.?

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>