xfce4-power-manager doesn't suspend on lid closed (regression)

Bug #1349056 reported by flux242
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Xfce4 Power Manager
Fix Released
Medium
xfce4-power-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

with the bugfix https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740 and the package version 1.2.0-3ubuntu4.1 my laptop stopped going to sleep on lid closed. Neither when on AC nor on battery lid closed suspend works.

WORKAROUND: downgrade xfce4-power-manager and xfce4-power-manager-data packages version to 1.2.0-3ubuntu4

ps I do not have light-locker installed.

Revision history for this message
flux242 (flux242) wrote :

psps: I also had to define previously

HandleLidSwitch=ignore

in the /etc/systemd/logind.conf
for the lid suspend to work

which means that new package effectively renders this workaround invalid

Revision history for this message
flux242 (flux242) wrote :

well, after analyzing the patch Ive found that powermanager relies now on logind lid close event handler. Which means that HandleLidSwith=ignore is invalid now and should now be used with the package version 1.2.0-3ubuntu4.1 and up.

Revision history for this message
flux242 (flux242) wrote :

should NOT be used, not "should now be used"

Revision history for this message
Sean Davis (bluesabre) wrote :

Hi flux242,

With that bugfix, we had found a conflict with logind also trying to handle suspending on lid close, creating a race condition for xfce4-power-manager and light-locker. We introduced a new setting, "logind-handle-lid-switch", which (dis)allows logind handling that event. If you set this property to false, it should be equivalent to your workaround (we also have to do the same for light-locker). To do so...

xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false

Let me know if that works for you.

Revision history for this message
flux242 (flux242) wrote :

Hi Sean,

now the status. For the lid close event handler to work correctly with the xfce4-power-manager package version 1.2.0-3ubuntu4.1 one has to do the following:

1. Deifne the HandleLidSwitch=ignore in the /etc/systemd/logind.conf. If this is not done then logind will handle the event no matter what setting are effective in the xfce4-power-manager dialog.

2. Call xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s true
note the true predicate, because logic is inverted:
++ if ( LOGIND_RUNNING() )
++ {
++ g_object_get (G_OBJECT (manager->priv->conf),
++ LOGIND_HANDLE_LID_SWITCH, &logind_handle_lid_switch,
++ NULL);
++
++ if (!logind_handle_lid_switch)
++ return;
++ }

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfce4-power-manager (Ubuntu):
status: New → Confirmed
tags: added: regression-update
Revision history for this message
Kevin Brubeck Unhammer (unhammer) wrote :

In my case, I had previously had these lines in my /etc/systemd/logind.conf to make lid suspend work in 13.10:

HandleLidSwitch=ignore
LidSwitchIgnoreInhibited=no

After upgrading to 14.04, lid suspend only worked after _removing_ those lines.

(Note: I use xscreensaver instead of light-locker, and still have to have a daemon running that calls xflock4 on lid close since otherwise it won't lock on lid close even though I have it set to do that in xfce4-power-manager-settings. Not sure if that's related.)

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

Hi,

it seems that the logic for handling logind inhibitions is completely backward.

The keys are named logind-handle-<foo> (and default to TRUE) which seems to indicate that *logind* does the job, not xfce4-power-manager.

But when actually adding inhibitors, the code (http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n502) actually does the opposite: if the key is true, then xfpm considers that it has to do the job, and adds a dbus inhibitor.

That's completely confusing. Either the key names have to be changed, or the logic.

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

Created attachment 5614
invert the logind xfconf keys logic

This patch should fix the issue, I guess. It sets the default keys to FALSE, and then only add the inhibits if the current keys are FALSE.

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

Created attachment 5615
invert the logind xfconf keys logic

New version which also updates the variable names for more clarity.

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

Ping?

Revision history for this message
In , Eric Koegel (eric-koegel) wrote :

Simon and Sean were working on this so I'll let them take the lead :)

Revision history for this message
In , Sean Davis (bluesabre) wrote :

(In reply to Yves-Alexis Perez from comment #2)
> Created attachment 5615 [details]
> invert the logind xfconf keys logic
>
> New version which also updates the variable names for more clarity.

This patch seems to make sense of it all. Please apply it going forward.

Changed in xfce4-power-manager:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :
Changed in xfce4-power-manager:
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xfce4-power-manager - 1.4.0-1ubuntu2

---------------
xfce4-power-manager (1.4.0-1ubuntu2) utopic; urgency=medium

  * debian/patches/01_fix-logind-handle-lid-switch.patch:
    - Fixes suspend on lid-close (LP: #1349056)
 -- Sean Davis <email address hidden> Wed, 17 Sep 2014 06:27:39 -0400

Changed in xfce4-power-manager (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.