Description of problem: After a fresh boot, HAL correctly records the lid state of my laptop (open): lshal | grep button.state button.state.value = false (bool) On lid close, my acpi script calls pm-hibernate. Upon opening the lid and resuming I find: lshal | grep button.state button.state.value = true (bool) So hal thinks the lid is still closed After service haldaemon restart: lshal | grep button.state button.state.value = false (bool) hal again correctly thinks the lid is open Version-Release number of selected component (if applicable): pm-utils-0.15-1 hal-0.5.7-3 How reproducible: always Additional info: This is probably related to gnome-power-manager bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187396 However the hal confusion happens with gnome-power-manager off, so hopefully there is some nice way for pm-hibernate to reset it? Should also mention acpi correctly records the lid state in all cases -- so my acpi power management scripts work fine. The bug only seems to prevent me using gnome-power-manager
This is most likely kernel bug - the event for ACPI open is not sent out correctly. In fact, in HAL we work around this by rescanning the buttons on resume. But this obviously won't work with calling pm-suspend and/or pm-hibernate from the command line. Unless you put cruft like http://cvs.fedora.redhat.com/viewcvs/rpms/hal/FC-5/hal-0.5.7-lid-open-fix.patch?rev=1.1&view=auto into the pm hooks. Does dbus-send --system --print-reply --dest=org.freedesktop.Hal \ /org/freedesktop/Hal/devices/computer \ org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int:0 work instead? Replace ".Suspend int:0" with ".Hibernate" for hibernation instead. Thanks.
Comment 1: Replace "int:0" with "int32:0" My bad, sorry.
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.