Comment 57 for bug 33072

I'm sorry, I forgot to mention I had already applied the patch when I generated
the gpm output. Unfortunately it did not change the behavior.

The edited log I first posted shows the "removing the AC power" events, leading
to the unexpected hibernate.

Here is an explanation of the full log:
Start gpm on a freshly booted system. On my first attempt at getting the system
in a confused state, I hit the lid button with my finger, leaving the lid open.
Hibernate, then resume. Remove power cord. Things still seem to be working fine.
So it seems closing the lid, and reopening it after hibernating is important.
Plug power cord back in.
Close lid, hibernate. Open lid, then resume. Remove power cord, and unexpected
hibernate happens.

Another point: if the system is in a confused state, and I do "service haldaemon
restart" (which causes gpm to crash), and then restart gpm, things work normally.

Should also mention, that if I do not use gpm, but hibernate via acpi scripts
that call pm-hibernate, hal gets into the same confused state.
When the lid is open, I get:

lshal -l | grep button.state
  button.state.value = false (bool)

When the lid is open, and hal is confused I get:
 lshal -l | grep button.state
  button.state.value = true (bool)

Restarting hal sets this to false.

So one question is: should pm-hibernate be returning hal to a pristine state (in
which case the bug is in pm-utils), or should pm-hibernate only be called via
the hal scripts?