GNOME Bugzilla – Bug 597189
g-p-m suspending again after opening the lid when suspend changes VT
Last modified: 2010-02-10 22:31:43 UTC
When g-p-m is set to suspend when the lid is closed, it can then suspend again when opening the lid. What's happening is that there's a vt switch when suspending. This means that when coming back from suspend, we're not on the X vt, and so we have to go back there. It means we are not the currently active ConsoleKit session and we become active. It turns out that g-p-m also applies the policy when our ConsoleKit session becomes the active one, so when the vt changes back to X, we reapply the policy. And bam. See the debug trace below. TI:10:31:38 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_button_pressed_cb,778 - Button press event type=lid-down *** WARNING *** TI:10:31:38 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_play,221 - failed to play lid-close: File or data not found TI:10:31:38 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_lid_button_pressed,697 - Performing AC policy TI:10:31:38 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_perform_policy,509 - action: /apps/gnome-power-manager/buttons/lid_ac set to suspend (The lid has been closed on ac power.) TI:10:31:38 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_action_suspend,446 - suspending, reason: The lid has been closed on ac power. TI:10:31:38 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_allowed_suspend,151 - conf=1, fg=1, can=1 TI:10:31:38 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_get_lock_policy,227 - Using ScreenSaver settings (0) TI:10:31:38 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_suspend,279 - emitting sleep (gnome-power-manager:4600): devkit-power-gobject-DEBUG: DBUS timed out, but recovering TI:10:31:54 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_suspend,284 - emitting resume TI:10:31:55 TH:0x807cc00 FI:gpm-screensaver.c FN:gpm_screensaver_add_throttle,233 - adding throttle reason: 'L'écran du portable est rabattu': id 363323839 TI:10:31:55 TH:0x807cc00 FI:gpm-backlight.c FN:gpm_backlight_button_pressed_cb,346 - Button press event type=lid-down TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_client_changed_cb,858 - same state as before, ignoring TI:10:31:55 TH:0x807cc00 FI:gpm-idle.c FN:gpm_idle_idletime_alarm_expired_cb,379 - idletime alarm: 1 TI:10:31:55 TH:0x807cc00 FI:gpm-idle.c FN:gpm_idle_evaluate,213 - session_idle=0, session_inhibited=0, x_idle=1 TI:10:31:55 TH:0x807cc00 FI:gpm-idle.c FN:gpm_idle_evaluate,267 - normal to dim TI:10:31:55 TH:0x807cc00 FI:gpm-idle.c FN:gpm_idle_set_mode,133 - Doing a state transition: dim TI:10:31:55 TH:0x807cc00 FI:gpm-idle.c FN:gpm_idle_evaluate,275 - setting up blank callback for 300s TI:10:31:55 TH:0x807cc00 FI:egg-console-kit.c FN:egg_console_kit_active_changed_cb,239 - emitting active: 0 TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_console_kit_active_changed_cb,1770 - console now inactive TI:10:31:55 TH:0x807cc00 FI:egg-console-kit.c FN:egg_console_kit_active_changed_cb,239 - emitting active: 1 TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_console_kit_active_changed_cb,1770 - console now active TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_console_kit_active_changed_cb,1783 - Performing AC policy as become active when lid down TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_perform_policy,509 - action: /apps/gnome-power-manager/buttons/lid_ac set to suspend (The lid has been found closed on ac power.) TI:10:31:55 TH:0x807cc00 FI:gpm-manager.c FN:gpm_manager_action_suspend,446 - suspending, reason: The lid has been found closed on ac power. TI:10:31:55 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_allowed_suspend,151 - conf=1, fg=1, can=1 TI:10:31:55 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_get_lock_policy,227 - Using ScreenSaver settings (0) TI:10:31:55 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_suspend,279 - emitting sleep (gnome-power-manager:4600): devkit-power-gobject-DEBUG: DBUS timed out, but recovering TI:10:32:06 TH:0x807cc00 FI:gpm-control.c FN:gpm_control_suspend,284 - emitting resume
Oh, and obviously, the issue is that gpm_button_is_lid_closed (manager->priv->button) returns TRUE when we come back from suspend while the lid is, hrm, not closed anymore :-)
Isn't the vt switch now not needed in a post-modeset world? I certainly don't get the double suspend here, but I'm using a pm-utils that doesn't do the vt switch for modeset drivers.
(In reply to comment #2) > Isn't the vt switch now not needed in a post-modeset world? I certainly don't > get the double suspend here, but I'm using a pm-utils that doesn't do the vt > switch for modeset drivers. Hrm, I honestly can't answer this question :-) I know that in openSUSE, we don't have the latest pm-utils, so that could be part of it. But looking closer, it seems to just be a race between the signal sent by ConsoleKit and the signal sent by DK-power. It's probably possible to avoid this race by directly poking at the DK-power property when needed instead of waiting for the callback.
Created attachment 144655 [details] [review] Directly poke at the DK-power property when needed So I tried this (see the patch), but it doesn't work. DK-power takes some time to realize the lid is opened again, it seems (it only realizes that when coming back from the second suspend) :/
Created attachment 144790 [details] [review] Emit CK changed events in the idle loop Here's how I'm fixing it for openSUSE: the core of the issue is that we receive two consecutive CK events (changed to inactive and then changed to active) before the lid-up signal. Now, by emitting those signals in the idle loop, we can actually look if they're useful or not. In this specific case: we know that the last known status was "active", and when we go to "inactive", and then "active", we will emit just one changed signal with "active". Except that since the last known status was "active", there's no point in sending the signal. So we end up not sending anything. (Note that simply emitting the signals in the idle loop is working too, since it changes the race issue: we get the DK-power event before the CK event; but it's still a race that can't be trusted)
Shouldn't this be fixed in ConsoleKit itself?
Well... It depends. Strictly speaking, the active console was indeed changed, so CK is right to send those events, I guess. It's just that in g-p-m we do some action that is really visible in a big way on those events, so we have to be a bit more careful. (I can imagine some app that would log the events -- this app would not want the CK behavior to be changed)
I guess commit 8a500832d83ba9a548ce6b22cf54aaada5806a9f fixes this another way...