After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 585228 - immediately suspends on startup when lid is closed
immediately suspends on startup when lid is closed
Status: RESOLVED NOTGNOME
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.27.x
Other Linux
: Normal major
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-06-09 09:50 UTC by Martin Pitt
Modified: 2009-07-01 08:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Pitt 2009-06-09 09:50:13 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
Comment 1 Martin Pitt 2009-06-19 09:18:29 UTC
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
Comment 2 Martin Pitt 2009-07-01 08:13:07 UTC
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?
Comment 3 Martin Pitt 2009-07-01 08:29:11 UTC
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