Power Manager settings are ignored when closing laptop lid

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

Same problem on fresh install of 14.04 and the workaround from https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1222021 of editing /etc/systemd/logind.conf is effective.

Is the action for lid close still ignored? Make sure that xfce4-power-manager 1.2.0-3ubuntu4.1 is installed and the workaround mentioned in this report is NOT applied.

I have the same issue with my system going to sleep when I close the lid. The option "When laptop lid is closed" is set to "Nothing" for AC and battery. I have xfce4-power-manager 1.2.0-3ubuntu4.1 installed and did not apply the workaround.
Is there anything I could provide helping to solve this?

Bug is not fixed. I have xfce4-power-manager 1.2.0-3ubuntu4.1 installed. I reverted the "/etc/systemd/logind.conf" workaround and rebooted. My laptop still goes into sleep mode and the monitor is black until I do a hard reboot. The only drop-down option that has any effect in xfce4-power-manager is the 'System tray icon'.

I also disabled light-locker in case that was interfering with power manager, but the behaviour did not change.

I confirm this bug on Asus K53SD, either fresh intall of Xubuntu or first install Ubuntu and then apt-get install xubuntu-desktop.

Also confirmed on Dell Latitude D400 on completely new install of Xubuntu 14.04.1 despite claims to the contrary on the website.

Xubuntu up to 12.04.4 worked absolutely correctly before new install of 14.04.1

Using the "Suspend" key results in correct operation, i.e. the laptop suspends and resumes correctly. Only closing the laptop lid results in the black screen when re-opening. Once in black screen mode, the only recourse is power off re-boot.

This is a MAJOR inconvenience for an upgrade of an LTS.

I can confirm that the reported behaviour (sleep on closing laptop lid) occurs following a clean install of 14.04.1 on an Acer AO725.

See also Bug #1357090 now set to be looked at for 14.04.2 which is a renewed instance of "Resolved" Bug #1303736 and is, I think, related to this, thought maybe not a "Duplicate".

The behaviour I'm seeing is that the laptop does NOT suspend correctly on lid close, but DOES when "Suspend" key is pressed or Log-off "Suspend" option is clicked.

There are obviously variants to the behaviour and possibly different causes, but in my case the system NEVER suspends correctly on lid close, even though the power-manager-settings are set to "Suspend"

Just installed a fresh copy of Xubuntu 14.04.1 and I also have that problem. In addition after wakeup the screen stays black after the password dialog. I don't mind, because I wouldn't want to go into sleep mode anyways. So I hope this can be fixed properly any time soon.

"This is a MAJOR inconvenience for an upgrade of an LTS."

Yes, for me I don't mind and I know things like this happen, but for normal users that may be a very disappointing experience.

I can confirm the same behaviour. Computer goes to StandBy when lid is closed after awakening the screen keeps black.

 xfce4-power-manager 1.2.0-3ubuntu4.1 is installed and no work around is applied.

I deinstalled light-locker and installed xscreensaver again but the same problem occurs. When I deinstalled both I can not lock the screen anymore.

In case editing the logind.conf file doesnt work:

#this removes some settings which will be recreated again
rm ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml

This solved the problem for me.

Same in utopic with xfce4-power-manager 1.4.1-0ubuntu1.

Hi, same bug for me , Xubuntu 14.04 and power manager 1.2.0-3ubuntu4.1

Laptop : Dell Latitude E5440

Editing "/etc/systemd/logind.conf" disable sleep when closing lid, but screen stay on
and if not editing "/etc/systemd/logind.conf", sleep when closing lid even "lock screen" selected

For all those who have no success editing /etc/systemd/logind.conf or found that rm ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml only works temporarily, I had success using gksudo gedit /etc/UPower/UPower.conf and then setting IgnoreLid=true.

A second work around is to hit ctrl+alt+f1, sign in using your username(lower-case) and password, then enter sudo restart lightdm, followed by your password again (some times this has to be done all with a pitch black screen)

Not ideal I know but is the best solution i've found.

Actually this second workaround is more relevant to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1357090 ...my bad

I was suffering from both issues, still no real fix for either for me

Lets try to debug the actual problem (Power Manager settings are ignored when closing laptop lid).

Please restore the default setup by reverting changes to /etc/systemd/logind.conf. and deleting /home/<user>/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml. After doing so and relogging once, open a terminal window and run the following commands to restart the power manager in debug mode:

killall xfce4-power-manager
xfce4-power-manager --debug

Now close and re-open the lid to trigger the bug and attach the terminal output to this report. Once you have closed the terminal window, you may want to launch "xfce4-power-manager" again to restore its functionality.

Thanks in advance.

Bug affecting a Acer Aspire 7715

:

Fresh install and update of xubuntu utopic. In this case all settings in logind.conf are set to their defaults:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

log created by killall xfce4-power-manager && xfce4-power-manager --debug > xfpm_debug.log 2>&1

Thanks for the feedback so far. Can you please also attach the output of "xfconf-query -c xfce4-power-manager -l -v" to this report (I did forget to mention this).

Furthermore, does the power manager ignore every possible lid close action or just a specific one? What happens instead?

Output of "xfconf-query -c xfce4-power-manager -l -v" as requested.

In my case (utopic, xfpm 1.4.1), setting the lid close action to 'switch off display', works as expected: the system does not suspend. I've attached a xfpm debug log for that case.

I should add a few things concerning my comments #22 and #23: All outputs are from a utopic system. For light-locker to work properly in utopic (see https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1303736?comments=all) the xfpm xconf setting "/xfce4-power-manager/logind-handle-lid-switch" has to be set to "true" (this seems to have changed since trusty). This means the findings in #22, #23 are still valid, but with these settings the screen stays blank after unlocking after resume.
If one uses the proper settings for light-locker (/xfce4-power-manager/logind-handle-lid-switch = true) in utopic, then the system suspends in either case (lid close action: lock or blank).

The log file from comment #19 shows that xfwm4-power-manager does not inhibit sleep on lid close (the key "handle-lid-switch" is missing for "Inhibiting systemd sleep"). We will have to wait for the output of the xfconf-query command.

Now, b3nmore, the bottom line of your feedback is that the bug does not affect utopic with default settings. Also, why should the default value for logind-handle-lid-switch (false) be changed? Your screen staying blank may have a different cause.

> Now, b3nmore, the bottom line of your feedback is that the bug does not affect utopic with default settings.

No (sorry, I should have mentioned, that #20 is from the same system), with the default settings in utopic we have:
lid action: result:
switch off display switches off display
lock screen suspends (and locks screen)

However, with those settings, the screen stays blank after unlocking a system resumed from a lid closed triggered suspend. To correct this issue, "xfce4-power-manager/logind-handle-lid-switch" has to be set to "true". Btw., this is what happens, if one disables and enables light-locker via the gui [1], [2].

Now, with the correct light-locker settings we get:
lid action: result:
switch off display suspends (and locks screen)
lock screen suspends (and locks screen)

[1] cf. http://xubuntu.org/news/laptop-users-fix-available-for-the-black-screen-on-unlock-bug/
[2] # defaults after creating new user
$ xfconf-query -c xfce4-power-manager -l -v
/xfce4-power-manager/blank-on-ac 15
/xfce4-power-manager/blank-on-battery 10
/xfce4-power-manager/brightness-switch 0
/xfce4-power-manager/brightness-switch-restore-on-exit 0
/xfce4-power-manager/dpms-enabled true
/xfce4-power-manager/dpms-on-ac-off 60
/xfce4-power-manager/dpms-on-ac-sleep 20
/xfce4-power-manager/dpms-on-battery-off 30
/xfce4-power-manager/dpms-on-battery-sleep 15
/xfce4-power-manager/lock-screen-suspend-hibernate true
/xfce4-power-manager/logind-handle-lid-switch false
/xfce4-power-manager/power-button-action 3

#above settings trigger blank bug (unblank by blindly starting a terminal and execute "xrandr --auto")

# disabling and enabling light-locker via settings gui
$ xfconf-query -c xfce4-power-manager -l -v
/xfce4-power-manager/blank-on-ac 15
/xfce4-power-manager/blank-on-battery 10
/xfce4-power-manager/brightness-switch 0
/xfce4-power-manager/brightness-switch-restore-on-exit 0
/xfce4-power-manager/dpms-enabled true
/xfce4-power-manager/dpms-on-ac-off 60
/xfce4-power-manager/dpms-on-ac-sleep 20
/xfce4-power-manager/dpms-on-battery-off 30
/xfce4-power-manager/dpms-on-battery-sleep 15
/xfce4-power-manager/lock-screen-suspend-hibernate true
/xfce4-power-manager/logind-handle-lid-switch true
/xfce4-power-manager/power-button-action 3

> Also, why should the default value for logind-handle-lid-switch (false) be changed?

The default settings 'revive' the blank-screen-after-unlock bug (at least for a resume after a lid close triggered suspend). So IMO the default settings are not correct in this respect.

> Your screen staying blank may have a different cause.

I don't think so, because the symptoms and workarounds (e.g. xandr --auto) sound quite familiar.

I did the same tests for trusty: The behavior is basically the same, only the xfce4-power-manager/logind-handle-lid-switch xfconf-key is handled oppositional (probably due to http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=f62e82256cb2a45b4f044b7d603017952f7dd63e).

Let's try to summarize all findings:
trusty case 1)
    xfce4-power-manager/logind-handle-lid-switch = true
    -> blank-screen bug with light-locker
    -> debug trace: xfpm_manager_inhibit_sleep_systemd(): [...] handle-lid-switch
    a) lid close action: nothing -> result: nothing
    b) lid close action: lock -> result: suspend + lock + blank bug

trusty case 2)
    xfce4-power-manager/logind-handle-lid-switch = false
    -> light-locker works
    -> debug trace: xfpm_manager_inhibit_sleep_systemd(): [...]
    a) lid close action: nothing -> result: suspend + lock
    b) lid close action: lock -> result: suspend + lock

utopic case 1)
    xfce4-power-manager/logind-handle-lid-switch = true
    -> light-locker works
    -> debug trace: xfpm_manager_inhibit_sleep_systemd(): [...]
    a) lid close action: nothing -> result: suspend + lock
    b) lid close action: lock -> result: suspend + lock

utopic case 2)
    xfce4-power-manager/logind-handle-lid-switch = false
    -> blank-screen bug with light-locker
    -> debug trace: xfpm_manager_inhibit_sleep_systemd(): [...] handle-lid-switch
    a) lid close action: nothing -> result: nothing
    b) lid close action: lock -> result: suspend + lock + blank bug

> The log file from comment #19 shows that xfwm4-power-manager does not inhibit sleep on lid close (the key "handle-lid-switch" is missing for "Inhibiting systemd sleep").

From the analysis above I would guess, that it is either trusty case 2 or utopic case 1.

And a small variation:
trusty 1 b) BUT with light-locker disabled -> result: nothing

No locking (well light-locker is disabled, no surprise there) and no suspending. Might it be, that light-locker somehow triggers the suspend?

b3nmore, thank you very much for the all the debugging you have done. I will discuss your test results with the actual developers, so we can hopefully resolve this issue once and for all.

Furthermore, bug 1387413 seems to be related (it was closed for no reason).

I'm still seeing this bug on 14.10.

There are suggestions floating around the web to the effect that it's caused by systemd.

One suggested solution is to add the following to /etc/systemd/logind.conf :
HandleLidSwitch=ignore
LidSwitchIgnoreInhibited=no

I've done so, but have not rebooted to see the result.

Here are my observations:

1) The initial value of logind-handle-lid-switch is "false" in 14.10. This appears to be correct, because the default lid close action is "lock" and not "suspend".

2) Changing the value to "true" is required to work around the infamous blank-screen-after-unlock bug and will let logind initiate the suspend sequence (according to logind.conf). However, this is only needed when "suspend" is selected as lid close action in xfce4-power-manager-settings.

3) As of now, logind-handle-lid-switch is set via light-locker-settings (lock on suspend -> true, otherwise false). There is no smart check.

4) The proper fix would be to patch xfce4-power-manager. It should be able to evaluate certain conditions (light-locker running? lock on suspend enabled?) and set logind-handle-lid-switch accordingly when the lid close action is changed by the user.

While looking at the test results in comment #28, one thing remains unsolved:

Why does the system suspend in test case "trusty 1b" and "utopic 2b"? The screen should be only locked and neither logind nor xfce4-power-manager should trigger suspend.

b3nmore, please add "HandleLidSwitch=ignore" to your logind.conf and rerun the test cases which are mentioned in my previous comment.

> b3nmore, please add "HandleLidSwitch=ignore" to your logind.conf and rerun the test cases which are mentioned in my previous comment.

Running "utopic 2b" with "HandleLidSwitch=ignore":
result: lock + blank-screen-after-unlock bug.

> Why does the system suspend in test case "trusty 1b" and "utopic 2b"? The screen should be only locked and neither logind nor xfce4-power-manager should trigger suspend.

Neither does (cf. #30, its the same for utopic 2b), at least not in combination with other screen lockers. I've tested i3lock and the system does exactly as configured in xfpm.

So the questions is more specifically: why does the system suspend in those cases, *if* we use light-locker as locking application?

I've tried to dig into this issue, and this is what I've got so far:
- if set to lock sreen, xfpm calls "xflock4"
- if light-locker is running, xflock4 calls "light-locker-command -l"
- running "light-locker --debug" shows in this case (i.e. lid triggered):
gs-listener-dbus.c: obj_path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager method=PrepareForSleep destination=(null)

- when calling "xflock4" manually, xflock4 calls "light-locker-command -l"
- running "light-locker --debug" shows now:
gs-listener-dbus.c: obj_path=/org/freedesktop/login1/session/c2 interface=org.freedesktop.login1.Session method=Lock destination=(null)

This means, that somehow in the combination xfpm + light-locker (and only in this combination) a suspend call is sent to (?) logind (and therefor a PrepareForSleep-Signal is emitted). I've been unable to identify, where the suspend call comes from.

Just to make this clear:
xfpm is setup to inhibit systemd/logind's lid handling and to lock the screen on lid close:
xfpm + i3lock -> no suspend
xflock4 + light-locker -> no suspend
xfpm + light-locker -> suspend

Unfortunately I've to revise the results for "trusty 1a" and "utopic 2a" resp.. There is a delay of ~5 sec. before the system suspends (in the other cases its suspends immediately, hence my misinterpretation). So they should be:
result: 5sec. nothing + suspend + lock + blank-screen-after-unlock bug

I've verified, that we get different timings for utopic 2a/2b (or trusty 1a/1b) by adding a 'sleep 20' at the start of the xflock4 script. in that case "utopic 2a" suspends after 5 sec., "utopic 2b" after 20 sec.

And with the modified xflock4, we can do another variation of "utopic 2 b":
- close lid and wait 15 sec. -> nothing happens
- open lid -> screen gets turned on
- wait 5 sec. more -> light-locker locks the screen, but does *not* suspend
- after unlocking screen just gets turned on

The last test of the previous comment seems to imply, that we get the unwanted suspending only, if light-locker locks the screen *while* the lid is closed. Heres a test to verify this and takes xfpm out of the whole mess (on utopic):
- killall xfce4-power-manager
- systemd-inhibit --what=handle-lid-switch --who=me --why=test --mode=block sleep 1000
This blocks any action logind may take upon lid close (for 1000 sec.), i.e. one can close the lid and nothing happens.
- sleep 20 && light-locker-command -l
- close the lid

Result: 20 sec. happens nothing (you can even open/close the lid several times). If the lid is closed when "light-locker-command -l" runs, the system suspends.

I would guess, that light-locker lifts the block of the 'handle-lid-switch' and, if the lid is closed, theres still a lid close event pending, which than gets executed (or something of the kind).

The case "utopic 2a" (or "trusty 1a") is basically the same as above, only that the actual lock time depends on how the "lock-after-screensaver"-time of light-locker is configured. Again a test, that keeps xfpm out of the picture:
- killall xfce4-power-manager
- systemd-inhibit --what=handle-lid-switch --who=me --why=test --mode=block sleep 1000
- light-locker --lock-after-screensaver=1
- sleep 20 && xset dpms force off
- close lid

Result: 20 sec. nothing, light-locker registers the screen blanking and locks the screen, if the lid is closed the system suspends.

O.k., so light-locker calls lightdm to lock the seat. So we can skip light-locker in the tests above and use e.g. "dm-tool lock".

That means, that it is lightdm, which seems to override the inhibitor lock for the lid handle upon locking.

Btw. running above tests only with dm-tool (no xfpm and no light-locker) shows, that the screen stays switched off in the same situation as with the 'infamous blank-screen-after-unlock bug'....

I still have to read and analyze your previous comments and test results. Hopefully I am not missing something, so please rerun the test case from comment #40, but also activate the "late locking" feature of light-locker:

light-locker --lock-after-screensaver=1 --late-locking

This way the active seat/context should not change (no switch to VT8 until keyboard/mouse input).

Thank you very much for all the testing.

> ... rerun the test case from comment #40, but also activate the "late locking" feature of light-locker:

This does work.

It is expected to work, since the lock command is called after the lid is open again.

Apropos vt switch, I believe, thats the root cause of this issue and the blank-after-unlock bug. If we have a vt switch (e.g. "sleep 20 && loginctl activate cX" in the examples above) *after* the lid was closed, then the system suspends; maybe because the new session has no inhibitor lock. When the lid is open, the screen gets turned on for the new active session. When we switch back to the original session, the screen turns off, because on this sessions it was deactivated, but never reactivated.

I've tested this behavior on text vt's and there is the same retroactive suspend reaction of a closed lid.

You are right. We need to understand how the systemd inhibit mechanism works and why it is not applied system-wide.

I suggest that we use the current Xubuntu development release (vivid) as base for further testing:
- The power manager is now able to detect and configure light-locker. Therefore, the logind-handle-lid-switch property can be changed on-the-fly.
- The new version of light-locker (1.5.x) can be controlled with additional DBus calls, so it should be possible to find a solution which does not trigger the unwanted "xflock4 -> light-locker-command > VT switch > suspend" chain.

> We need to understand how the systemd inhibit mechanism works and why it is not applied system-wide.

I've asked at the systemd-devel list, if they want to keep this behavior (after all, it is a design decision): http://lists.freedesktop.org/archives/systemd-devel/2015-January/027255.html.

> ... the logind-handle-lid-switch property can be changed on-the-fly.

Judging from the code, the logind-handle-lid-switch property causes xfpm to ignore the lid switch event, if set to true. That means, that if you want to set the action for the lid close event in xfpm (that is, that xfpm reacts on such an event), this property must not be set to true. Else logind will handle the event and executes what ever is defined in logind.conf.

IMO this property should be removed, its confusing and xfpm has the ability to handle lid switch events.

Yes, we know this. The logjnd-handle-lid-switch property is being used as "fix" for the blank screen bug.
If logind handles the lid event, it will send two separate signals which control light-locker (lock session before suspend, switch to unlock screen on resume).

> Yes, we know this. The logjnd-handle-lid-switch property is being used as "fix" for the blank screen bug. If logind handles the lid event, it will send two separate signals which control light-locker (lock session before suspend, switch to unlock screen on resume).

Ah, I suspected something of the kind.

Here is a summary of the issues (as I understand it): The vt switching by light-locker (or rather lightdm) is the root cause for two issues, which were attributed to xfpm, but have nothing to do with xfpm:
1) system suspends in certain situations, although xfpm is configured not to suspend in those situations
2) in certain situations the screen stays switched off after unlocking

Besides the trivial case for 1), cf. comment #48, both issues arise, if the lid is closed when the vt switch happens. If we call the user session vt1 and the unlock screen session vt2, the event chains look (approximately) as followed:
1) lid close on vt1 -> xfpm blocks logind and executes as configured -> screen locks and switches to vt2 -> vt2 has no logind inhibitor log -> logind suspends the system.
2) lid close on vt1 -> xserver (?) switches the screen off for vt1 -> screen locks and switches to vt2 -> user wants to unlock -> screen gets switched on on current active sesion, i.e vt2 -> authentication -> switch to vt1 -> turned off screen, because on vt1 it was never switched on again

If this analysis is correct, we have two approaches to solve both issues:
a) adapt light-locker to never make a vt switch while the lid is closed. That would be something like making late-locking a general behavior.
b) adapt light-locker (or maybe even lightdm) to tackle each problem on its own. E.g. the unlock screen session needs an inhibitor lock too and possibly turn on the screen of the session it switches to after unlocking.

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

b3nmore, there is some progress now and we need to test the following light-locker branch:

https://github.com/the-cavalry/light-locker/tree/lid-closed

It basically adds lid closed detection which should prevent the vt switch before suspend. Hopefully we can get it packaged soon for easier testing.

A modified light-locker package is now available for 14.10 / 15.04:

https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging

Please test and report back.

The two new options here can be found on the command line:

  --lock-on-lid Lock the screen on lid close
  --no-lock-on-lid Do not lock the screen on lid close

and in dconf-editor under apps.light-locker

"lock-on-lid"

Please provide additional feedback so we can finally resolve this bug.

Thanks for your help!

I've tested light-locker version 1.6.0-0ubuntu1 on vivid with the staging repository enabled (although the light-locker from vivid currently supersedes the staging one).

Good news first: the system does not suspend anymore when it is configured to lock only (case 1 from #50). It does not suspend even when explicitly locking on lid close (--lock-on-lid). Shouldn't this reproduce the old behavior?

Bad news: the screen stays still switched off after unlocking (case 2 from #50). I couldn't see any differences between lock-on-lid and no-lock-on-lid (cf. attached debug logs). And I'm not sure why this still happens. Maybe the switch is too fast to activate the screen on the original session first. If our analysis is correct so far, we would need to activate the screen on the session where it got deactivated first and than do the switch.

Attached log is from "light-locker --debug --no-lock-on-lid", I commented the triggering actions.

Just as reference: attached log is from "light-locker --debug --lock-on-lid", I commented the triggering actions. Only difference to previous log are lines 92 and 93.

Ah, I used a modified logind.conf for the tests in #55/#56. It had HandleLidSwitch=ignore, so thats probably the reason, why the system didn't suspend.

When using an unmodified logind.conf, i.e. all options commented out, the system suspends regardless of which option (--lock-on-lid/--no-lock-on-lid) I use. Odd exception: sometimes the first try after reboot does not suspend; again independent of the used option.

So my guess is, that we still have some vt switching while the lid is closed.

There was a flaw wit the previous patch to detect lid status. It doesn't work in combination with systemd.
There is a new commit in the upstream branch that resolves this.

When someone has updated the PPA you can test this again.

It would be good to know if this would also work we HandleLidSwitch set to suspend to test if the timeouts are in order.

Now it works for about 10s. After 10s the system suspends. I still don't see any differences between --lock-on-lid and --no-lock-on-lid.

I've attached a commented debug log for "light-locker --debug --no-lock-on-lid", systemd handleLidSwitch is configured to suspend. The log contains 2 lid close/open cycles, the first took 8s (to prevent suspend), the second 30s.

Thank you for testing. This is very much appreciated and we are getting closer to a solution.

The switch to greeter timers wasn't stopped by the closed lid. I've pushed another patch to do this.
If lock screen is selected in the power manager, --lock-on-lid / --no-lock-on-lid should not change the behaviour.

Could you also test with suspend/hibernate selected in the power manager. both with --no-lock-on-lid and --lock-on-lid.
To test if the screen stays blank still occurs. I can't reproduce that on my system, so I rely on the reporter to test this.

I ran some tests, which I recall having caused problems in the past. With the latest patch (b529706) applied, the two main issues (unwanted suspend/blank screen) are basically resolved now for *all* test cases (except maybe f) 1/2).

There are small differences for the various configuration options, which I'll list for each test case. IMO the ideal case would be, that the 'unlock dialog appears directly'. However sometimes the user must interfere manually a second time or wait additional time [1].

1) --no-lock-on-lid
2) --lock-on-lid

Test cases directly triggered by lid close:
a) xfpm lid action: lock
   i) auto lock: never
   1) delay OR manual interference (depends on close time)
   2) unlock dialog appears directly (depends on close time)
   ii) auto lock: ss activates (after autolock kicks in)
   1) delay OR manual interference
   2) unlock dialog appears directly
   iii) auto lock: ss deactivates (after autolock kicks in)
          1) delay OR manual interference
   2) unlock dialog appears directly

b) xfpm lid action: suspend
      1) unlock dialog appears directly
      2) unlock dialog appears directly

c) xfpm lid action: hibernate
      1) manual interference required
      2) manual interference required

Test cases auto lock, lid stays open (xfpm lid action: lock):
d) auto lock: ss activates
   1) unlock dialog appears directly
   2) unlock dialog appears directly
e) auto lock: ss deactivates
   1) manual interference required
   2) manual interference required

Test cases auto lock, but lid gets closed *after* the screen was locked (xfpm lid action: lock):
f) auto lock: ss activates
   1) system suspends, manual interference required
   2) system suspends, manual interference required
g) auto lock: ss deactivates
   1) manual interference required
   2) manual interference required

[1] I would call them usability issues, because the user has to take additional action although he already requested the unlock dialog by e.g opening the lid etc. So nothing really dramatic, but the user interaction required to get to the unlock screen heavily depends on situation and isn't consistent (and maybe discussed elsewhere).

Seems to work in Xubuntu 15.04 (had the problem in 14.10 and it's fine after I upgraded). Please change it back to 'Confirmed' if you can reproduce the bug in 15.04 or nominate it to be logged as Confirmed in the 'Trusty' series if it's still not fixed there. I imagine it was probably a fix in Xfce 4.12 so probably not fixed in 14.04 still.

Yes, it should be fixed in Xubuntu 15.04 which installs a patched light-locker version. Sadly, I do not know if the fix can be backported to older releases.

Thank you all for the thorough testing.

As with the results of #61, the intial problem is solved with the right combination of settings.
While prepering this patch to be brought into master it became clear there are still some corner cases with this patch before it is ready.
Meanwhile this patch will do fine.
If (new) usability issues appear, these can be handled in other reports.

As to backporting, I've tried backporting (this or another patch) to the 14.10 version. However, there are many addition in the intermediate versions which result in comprehesive patches or backporting more features resulting in an upgrade more or less.

> ... nominate it to be logged as Confirmed in the 'Trusty' series if it's still not fixed there.

Can someone (who has the permission) nominate this for trusty? Trusty will be around for a while and there is right now no real workaround (or fix for that matter). So it should be at least documented.

I'm having this issue on 15.04, or a weird version of the issue.

Even when plugged into an outlet, it is only using the laptop lid settings for if I am on battery, despite being on AC power.

I'm still seeing this on Lubuntu 15.04. Xfce power manager is set to lock screen on lid close, but it's still going to sleep.

light-locker 1.6.0-0ubuntu2
xfce4-power-manager 1.4.3-0ubuntu1

Bug still present in xfce4-power-manager 1.4.4

I was suffering from this bug (or one with similar symptoms) in Ubuntu 15.10 in xfce4-power-manager 1.4.4. The following command fixed it:
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false

I can confirm that even in Ubuntu 15.10 one has to set the 'logind-handle-lid-switch' to false manually. Please switch to use false by default for the Ubuntu 16.04 LTS. The code doesn't need to be changed, its just enough to add the following command into the package installation script:
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -n -t bool -s false

When I probe that configuration parameter, it responds with false on my install of 15.10 Xubuntu. Yet when my lid is closed while in my docking station (two external monitors connected), the system puts it in suspend mode after a short time. Is there still some default setting I have to mess with, because I honestly cannot seem to find any settings I need to toggle/tweak.

This bug is STILL THERE in Xubuntu 16.04.1!
And it is REALLY annoying!
I can handle it as an experienced user, but for a normal user editing /etc/systemd/logind.conf is a no-go!

I can confirm that this bug still affect users. I am booting Ubuntu from Thinkpad T430s, I think at least this bug should be mentioned in the xfce4-power-manager package release.

It took me serveral hours to figure why my laptop is not working

Confirming the but is still present. If the setting on power manager is set to "switch off display", upon closing the lid on a fresh install of Xubuntu 16.04 it still goes into suspend mode.

The solution proposed ( xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -n -t bool -s false) does not work for me.

Manually editing ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml the value of logind-handle-lid-switch from "empty" to type="bool" value="false" also doesn't work, as the value keeps reverting back to "empty".

The problem is exacerbated by the bug #1303736.

Curiously when the laptop lid option is set to "lock screen" instead, it is respected, and the computer only locks the screen.

Can confirm, this is STILL a problem.

I have the same issue on my Thinkpad x250
Laptop always goes to sleep ignoring the xfce4 power settings
xfce version : 4.12 on xubuntu 16.04.2 LTS
Is there a fix available

I have the same bug on bionic. I have set "Lock screen" for as close lid action for both battery and AC.
When I close lid with unlocked screen it works as expected.
But when I close lid with screen locked (with light-locker) laptop gets suspended.

Still occurring on 20.04.1 LTS. Laptop (Lenovo E490) has power connected, lid is closed, Automatic suspend when plugged in is disabled; still suspends after a while. I'll now try messing with logind.conf and see if I can get it to behave the way I want.