Comment 19 for bug 267682

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