XF86Standby does not trigger hibernate or sleep

Bug #269951 reported by Bryce Harrington on 2008-09-13
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-power-manager (Ubuntu)

Bug Description


On an Inspiron 1420 (and possibly other Dell models), the Standby key (Fn+F1 in my case, with a little half-moon on it) does not trigger a standby action (Hibernate or Sleep).

Both hibernate and sleep actions *can* be triggered from the battery icon, and will properly suspend and resume.

Running xev, the key is detected and forwarded up to Gnome by X, so I believe X is doing whatever it's supposed to do. The output from xev is:

 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

I can also hook XF86Standby to other Gnome actions, like launching the help browser, using gnome-keybinding-properties, and it successfully launches the help browser. So the key events are getting handled and propagated. However, from what I understand, hooking the key to Suspend in gnome-keybinding-properties is an obsolete way for setting this up. Regardless, it doesn't work anyway; the event seems to get lost somewhere in gdm and never runs the /usr/sbin/pm-suspend command that it seems to be configured to trigger. Running that command from the console does work at triggering sleep though.


This bug has been addressed via a one-line patch to gnome-power-manager. Jaunty is unaffected because HAL send XF86Standby as dbus event.


To reproduce this bug, try pressing the key that corresponds to XF86Standby.


There is no regression potential. This patch simply enables a hotkey that was disabled (and mislabeled) previously.

Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) wrote :
Martin Pitt (pitti) wrote :

The same happens on my Latitude D430 (which also worked fine under Hardy).

Bryce, /proc/acpi/event is busy because acpid is already connected to it. Stop it, then you can cat it:

$ sudo /etc/init.d/acpid stop
 * Stopping ACPI services... [ OK ]
$ sudo cat /proc/acpi/event
button/power PBTN 00000080 00000001

If I press Fn+F1 (hibernate) or Fn+F3 (battery status), nothing happens. If I press the power button, I get the output above.

Changed in linux:
status: New → Confirmed
Bryce Harrington (bryce) wrote :

Aha, thanks. I also don't see output for Fn+F1 or Fn+F3. When I hit the power button (even briefly), the system shutsdown.

Bryce Harrington (bryce) wrote :

Pitti, are you able to get any of the keys to work when in the guest account? (For me, the system gave me a brown screen when switching to the guest account, so I've not been able to test it.)

Bryce Harrington (bryce) wrote :

[Looks like there are many similar reported issues in acpi-support, so guessing it belongs there rather than in the kernel.]

Bryce Harrington [2008-09-17 0:27 -0000]:
> Pitti, are you able to get any of the keys to work when in the guest
> account?

No, as I said in the other bug, it doesn't work there either.

> (For me, the system gave me a brown screen when switching to
> the guest account, so I've not been able to test it.)

Might have been bug #269509, which compiz just recently worked around?
It's worth trying with current intrepid.


I am not having a problem with either suspend or hibernate using the fn-f1 or fn-esc keys. I am an Inspiron 1420 owner, with integrated nvidia graphics. The 1420 also ships with the integrated intel graphics. I suspect the user with the problem has not properly setup their machine for suspend/hibernate.

For suspend / resume to work reliably (using the fn-key combinations or otherwise), the owner must be using the proprietary nvidia module. No way around it.

They must make additional customizations for it to work.

I outlined the necessary steps here:


I am using Ubuntu 8.04.1 amd64 with all updates, and am not having this problem.

If there are further questions, please let me know.



Bryce Harrington (bryce) wrote :

Harvey, I have a 1420N which has Intel i965 graphics, not nvidia. And sleep / hibernate both do work properly if I invoke them from the battery icon or by closing the lid, as mentioned in the original report.

Harvey Muller (hlmuller) wrote :


Sorry for the noise, I should have read the bug you split this from, and read the initial post in this bug a little slower. But it looks like it is relative to the 1420N, and not the 1420.

My guess is your hotkey issue is acpi or hal related. I know a little about hal, and took a look in it's files looking for 1420 information. I didn't see anything on the hotkeys, which leads me to believe it's probably an acpi issue.



Bryce Harrington (bryce) wrote :

I would agree there. I had tried setting up a hal configuration for the keys but it didn't do anything (but that may just be a factor of my relative inexperience with hal). Anyway, I've been focusing today on the acpi angle; I notice we're considerably diverged from Debian in acpi-support so I'm looking into that.

Bryce Harrington (bryce) wrote :

In the original bug, they were able to restore functionality by adding some HAL rules to disable use of evdev for the device. I experimented around with doing something similar for Dell by disabling evdev for /dev/input/event4 (which xinput shows as 'Sleep Button'. It made no effect; in fact I don't think evdev is grabbing that key to begin with.

I'll experiment with it more; perhaps removing acpi-support would have an effect.

Bryce Harrington (bryce) wrote :

With acpi-support installed:

Fn+F1: Causes current application to lose focus; no other perceived action. It should trigger sleep.

Fn+F3: No perceived action. It should bring up a battery display.

Fn+F8: Causes the gnome-panel to start blinking a lot (several dozen times over a period of 30-60 seconds). It is the CRT/LCD button, and with no monitor connected I'd assume it should do nothing.

Fn+UP, Fn+DOWN: Brightness keys work as they should, although they only give 4 levels of brightness and I'd think they should provide more than that.

Bryce Harrington (bryce) wrote :

Removing acpi-support via this command:

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

Had no effect; all the keys behaved the same as in the previous comment.

Bryce Harrington (bryce) wrote :

Interestingly, I can suspend from tty:

 1. ctrl-alt-f1
 2. fn+f1
 3. ctrl-alt-f7
 <at this point, it goes ahead and hibernates>
 4. wait for it to finish shutting off, then click power button
 5. grub screen appears with choice of kernel to boot; let it timeout and use the default
 6. prompts to login; fill it in
 7. resumes the previous session correctly.

So the basic key handling seems to be in place, but something (X I guess) appears to be hijacking the key.

Harvey Muller (hlmuller) wrote :

I'm testing Ubuntu Intrepid amd64 desktop (Beta), and see the problem, hibernate is not initiated. It works correctly in Hardy amd64 8.04.1. Fn-Esc doesn't initiate suspend to ram, as it did previously either.

Suspend and Hibernate are initiated from the Shutdown icon, but are not successful. That's a separate bug report however.

I can neither suspend nor hibernate from a terminal using Bryce's method above. When attempting i get three rapid beeps from the pc speaker, and nothing else.

To be clear, this comment is for INTREPID only, as Hardy through Gutsy work as expected.

Han Chung (han+c) wrote :

Interesting, this also affects my Dell XPS M1210, key map for Suspend to Disk(Fn+F1), Scroll lock(Fn+F5) doesn't work. But the Suspend to Ram key(Fn+Esc) works.

Han Chung (han+c) wrote :

Sorry for double post, but forgot to mention that Ubuntu 8.04.1 worked perfectly before.

Leonard Rojas (rojas-5) wrote :


I landed here looking for something else, but I thought I'd add another machine to the list. Fn + F1 doesn't accomplish anything on my Dell laptop. It never occurred to me to actually try it until just now, since I usually use the logoff or screen saver panel applets in Gnome (or just close the lid) to trigger suspend/hibernate.

Don't have any other info, just wanted to let you know that this apparently affects the 1525n too. :)

description: updated
Changed in dell:
status: New → Fix Committed
Changed in gnome-power-manager:
status: Confirmed → Invalid
Martin Pitt (pitti) wrote :

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gnome-power-manager:
status: New → Fix Committed
Harvey Muller (hlmuller) wrote :


The Fn-F1 key now works as expected in Intrepid (tested on Xubuntu), sending the machine into suspend mode.


Changed in dell:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu8.2

gnome-power-manager (2.24.0-0ubuntu8.2) intrepid-proposed; urgency=low

  * Add 80-enable-hibernate-hotkey to re-enable the hibernate hotkey
    that wasn't working at Intrepid release. (LP: #269951)

 -- Mario Limonciello <email address hidden> Fri, 09 Jan 2009 13:34:42 -0600

Changed in gnome-power-manager:
status: Fix Committed → Fix Released
Colin Watson (cjwatson) wrote :

Copied to intrepid-updates following successful verification.

Xamusk (ronanpaixao) wrote :

In my machine, a Dell Vostro 1310, the Fn+F1 keys always trigger an hibernate action, completely ignoring the gnome-power-manager setting to ignore or to suspend.

Changed in somerville:
status: New → Fix Released
no longer affects: dell
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305562

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers