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).
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.
> 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.freedeskto p.Hal" /org/freedeskto p/Hal/devices/ computer org.freedesktop .Hal.Device. SystemPowerMana gement. 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-keybindin gs-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.