Comment 0 for bug 269951

[Splitting this out from bug 267682]

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). From what I gather, it is supposed to trigger hibernate.

Both hibernate and sleep actions *can* be triggered from the battery icon, and will properly suspend and resume (although networking is lost on resume from sleep, but that's a separate issue).

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.

I don't know if this is relevant, but I've tried viewing the contents of /proc/acpi/events, however it doesn't let me read it as I think it should:

~$ sudo cat /proc/acpi/event
[sudo] password for bryce:
cat: /proc/acpi/event: Device or resource busy

I'm not certain whether this is a kernel bug, acpi bug, hal, X, or...? Near as I can tell it's not X, but who knows.