XF86Standby does not trigger hibernate or sleep

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

Bug Description

IMPACT:

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.

ADDRESSING:

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

TEST CASE:

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

REGRESSION POTENTIAL:

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.

Bryce,

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:

    https://answers.launchpad.net/ubuntu/+question/37909

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.

Thanks,

Harvey

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 :

Bryce,

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.

Regards,

Harvey

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 :

INSPIRON 1525N (INTREPID)

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 :

Martin:

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

Harvey

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