GNOME Bugzilla – Bug 585228
immediately suspends on startup when lid is closed
Last modified: 2009-07-01 08:29:11 UTC
2.27.1 now enables suspend on lid close by default. This is great in principle, but it falls over if you keep your laptop in a docking station, and thus the lid is closed all the time. When g-p-m starts up, I guess the recent fix for lid properties [1] triggers a change event, and the computer suspends immediately. So for this problem I think g-p-m should not do any suspend/hibernate action on startup. Perhaps it is possible to fix the event generation to suppress the initial change event for lid status? Unfortunately I can't attach a g-p-m debug output, since suspend is broken for me right now (complete freeze after wakeup). Is there a way for g-p-m and/or DK-power to detect whether the laptop is docked? In this case, you pretty much never want to suspend the machine when you close the lid. This is a separate issue, though, and I'm happy to file a separate bug for this. $ devkit-power --dump Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC native-path: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC vendor: model: serial: power supply: yes updated: Tue Jun 9 11:41:27 2009 (185 seconds ago) has history: no has statistics: no line-power online: yes Daemon: daemon-version: 008 can-suspend: yes can-hibernate yes on-battery: no on-low-battery: no lid-is-closed: yes [1] http://git.gnome.org/cgit/gnome-power-manager/commit/?id=90000eb88dbc4ef404f6be0940a0b64572c588ff
As followup reports show, this also seems to happen if the lid is open in some cases. Do you need further debug information for this? (At least the original report should be pretty clear). Thanks, Martin
Ah, I already cursed heisenbugs and thought I was going mad. This only happens the very first time any gnome-power-manager gets started, since that triggers devkit-power d-bus activation. When dk-p starts, it sends a lid event apparently: TI:10:06:35 TH:0xcb3d00 FI:gpm-button.c FN:gpm_button_client_changed_cb,554 - ************* gpm_button_client_changed_cb: lid: 1 TI:10:06:35 TH:0xcb3d00 FI:gpm-button.c FN:gpm_button_emit_type,101 - emitting button-pressed : lid-down TI:10:06:35 TH:0xcb3d00 FI:gpm-manager.c FN:button_pressed_cb,737 - Button press event type=lid-down TI:10:06:35 TH:0xcb3d00 FI:gpm-manager.c FN:lid_button_pressed,645 - **************** lid_button_pressed 1 TI:10:06:35 TH:0xcb3d00 FI:gpm-manager.c FN:lid_button_pressed,658 - Performing AC policy TI:10:06:35 TH:0xcb3d00 FI:gpm-manager.c FN:manager_policy_do,408 - policy: /apps/gnome-power-manager/buttons/lid_ac So now I'm a bit unsure where the bug is: I think dk-p should not send lid events on startup, since with d-bus activation gnome-power-manager has little chance to check if it triggered it or if it was already running. Alternatively, g-p-m could not react to any event in the first couple of seconds of startup. Richard, what do you think?
I thought about this, and I concluded that it is correct to fix this in dk-p. After all, g-p-m should also work if dk-p is already running, so special-casing dk-p startup in g-p-m sounds weird. I moved this to dk-p now: https://bugs.freedesktop.org/show_bug.cgi?id=22574