Lid-close suspend: blank screen when switching to user session

[iam-TJ]

I'm currently testing Xubuntu 18.04 after a do-release-upgrade from 16.04.

I discovered a very weird issue. When doing S3 sleep via closing the lid, on resume the lock screen appears, I authenticate, but as soon as it switches to the user session the screen goes blank - not even a backlight.

Switching to other ttys works and they display correctly but the GUI user session remains blank.

If the system is manually suspended (not using the lid), then resumed either by opening the lid or pressing the power button, the GUI user session is fine.

I narrowed it down to xfce4-power-manager and discovered disabling the lock-screen cured the issue.

I cloned the repository and reviewed commits between 1.7 and 1.8. Fortunately there aren't many. Looking at 6365683 "Proper exit status for light-locker-command" I suspected the change in the SetActive return value, and reverted it.

After a build/install cycle I've found the system now behaves correctly so I think the change should be reverted. This is the commit I'm using:

diff --git a/src/gs-listener-x11.c b/src/gs-listener-x11.c
index 6f161a1..c88e09d 100644
--- a/src/gs-listener-x11.c
+++ b/src/gs-listener-x11.c
@@ -227,8+227,7 @@ gs_listener_x11_force_blanking (GSListenerX11 *listener,
 #else
         gdk_error_trap_pop ();
 #endif
-        /* TODO: what should the return value be? */
-        return active;
+        return FALSE;
 }
 
 void

[iam-TJ]

The patch hasn't fully cured the issue so I need to dig deeper. Any suggestions of how to debug this gratefully received.

It only happens when suspend is triggered by lid-close, and with this patch, not every time.

[iam-TJ]

Further testing including adding 5 gs_debug() statements to track the lid_close handling seems to point to this being a timing/race issue. Adding the debug statements and executing with --debug redirecting stdout to a file and I could not reproduce the problem.

I then selectively backed off each debug action until I'd switched back to using the Ubuntu system binary and the problem will not reproduce!

It feels as if some option somewhere has been set and that makes things work. Tomorrow I'm going to do a reboot test in case a clean reboot with no previous successful suspend/resume cycles will continue to trigger the issue.

Another datapoint. I discovered that when the screen is blank, if I do "systemctl suspend" from a console tty, wait for the PC to enter sleep, then close the lid and re-open it so the system resumes, the user session is again visible!

[iam-TJ]

Issue occurs with a fresh boot and with full debugging from my custom build. Seems to indicate a definite issue with timing although I'm not sure where. I left the greeter authentication screen for a couple of minutes before unlocking and the issue still occurred. Could be something in the timing of switching from vt8 to vt7.
light-locker.log

[iam-TJ]

I've just made a significant discovery. From tty1 I was monitoring the backlight brightness after noticing the console would dim after a certain time but switching to tty7 and back to tty1 it would be brighter again. This made me think the power-manager in the tty7 session was doing an idle dim.

$ while /bin/true; do sleep 1; cat /sys/class/backlight/intel_backlight/actual_brightness ; done
46
46
46

Alt+F7

0
0
0
0

Ctrl+Alt+F1

140
140
140
140

This seems to prove the problem is that the monitor brightness is being set to 0 on lid-close and not returned to it's previous value on resume.

The fact it only affects the user session, and seems time sensitive, suggests there is a race condition where - most likely - the session-internal value is not being set or being reset after being set. It also would explain why other consoles are fine.

[ochosi]

I don't think lightdm or light-locker interact with that part of the user session/settings.

In Xfce it's probably both xfce4-power-manager and xfsettingsd that react to upower's lid signals.

[iam-TJ]

light-locker has a dbus listener for lid_closed and does a lot of reconfiguration as a result.

[ochosi]

Tbh I haven't looked at the code in a longer while, but if three daemons try to configure the backlight that sounds like race conditions would be the most likely outcome (especially since the three don't talk to each other).

[ochosi]

Just so that it's documented, here are the two code pieces I referred to earlier:
https://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n450
https://git.xfce.org/xfce/xfce4-settings/tree/xfsettingsd/displays.c#n1337

Both are usually part of Xfce sessions. And then ofc there's logind - not sure if that one interacts with the display's DPMS status or anything too.

[purplesrl]

Having the same issue on Linux Mint 19 Xfce (based on Xubuntu 18.04, HP Probook 470 G2):

1. If I suspend/resume when logged out (lightdm), all works ok.
2. If I suspend when session is started, when I come back the login screen pops up, I login, but then all goes blank. System is functional, I can turn to Ctrl+Alt+f2 but then If I turn to ctrl+alt+f7 and then again, it no longer works, BUT if I press the power button, the system will gracefully shut down and the display will come back displaying the Linux Mint logo when powering off.

I will try to investigate to see if it's the brightness problem.

[purplesrl]

What seems to work is to set the action to Lock screen when the laptop lid is closed in the Xfce Power Manager settings, I think in this way xfce locks the screen when you close the lid, so it should work properly when you are back from suspend, at least it works for me.

http://i.imgur.com/BATGHtU.png

Update: I set it to suspend and it seems to work properly.

[iam-TJ]

purplesrl: Changing

XFCE Power Manager > General > Laptop Lid > On Battery = Lock Screen

doesn't help because the laptop is not being suspended when that is set.

I confirmed this by checking kern.log and/or syslog - the kernel doesn't freeze and suspend to S3 when the lid is closed.

The expected kernel messages would be:

ACPI: Preparing to enter system sleep state S3
ACPI: EC: event blocked
ACPI: EC: EC stopped
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
IRQ 46: no longer affine to CPU1
smpboot: CPU 1 is now offline
IRQ 48: no longer affine to CPU2
smpboot: CPU 2 is now offline
IRQ 47: no longer affine to CPU3
smpboot: CPU 3 is now offline
ACPI: Low-level resume complete
ACPI: EC: EC started
PM: Restoring platform NVS memory
Enabling non-boot CPUs ...

[purplesrl]

Yes, I noticed that also, this is why I updated my answer, I set it to "Suspend" and it works properly now:

http://i.imgur.com/CFuWg7J.png

This was my initial goal, to not suspend the laptop when the lid is closed so I set "When lid is closed" to "Switch off display", but the laptop still suspends (I guess that is the bug, as it should just turn off the display) and If I set it like that, then when it comes back, the display will remain blank after I login, but if I set it to "Lock screen" or "Suspend" it works.

[iam-TJ]

I hit this again on upgrading several laptops to Xubuntu 19.04.

Discovered it is a fight between xfce4-power-manager and systemd-logind. Solution is:

echo "HandleLidSwitch=ignore" | sudo tee -a /etc/systemd/logind.conf
echo "HandleLidSwitchExternalPower=ignore" | sudo tee -a /etc/systemd/logind.conf

[iam-TJ]

Seems to be caused by this xfce4-power-manager commit:

commit 10076da7caa49320b3e907d319a9f27ee6702969
Author: Sean Davis <bluesabre@ubuntu.com>
Date: Sat Feb 7 11:49:31 2015 +0300

    Light Locker Integration (Bug #11488)

    Integrate Light Locker configuration into Xfce Power Manager. This
    allows proper settings synchronization between the two applications
    and eliminates some of the hackiness used in Light Locker Settings
    to accomplish the same effect, and streamlines similar tools into
    a single location. This depends on light-locker 1.5.1 configured
    with the GSettings backend.

    Signed-off-by: Eric Koegel <eric.koegel@gmail.com>

[katsar0v]

Any update on this issue? I could reproduce it on ThinkPad t480s/t470s

[apolinux]

Please help! I have the same symptoms in my Asus X555q with xubuntu 19.04

[JamesTheAwesomeDude]

@iam-TJ, you are an absolute HERO. Thank you so much for putting in the work on this issue.

(Your workaround happened to work for me, but the greater point is that) you've taken a crack at nailing down this years-old, UXP-destroying bug as efficiently as possible. That's awesome.

I can finally use Linux for school now, without having to decide "hmm do I feel like risking being that guy if I slip up and break the OS while an important project is ongoing"

the sheer amount of eyes that have been on this problem (mostly in a context of sadness -- the paper trail on Launchpad is quite disheartening), before you came in and simply debugged it and found the problem, is just staggering and really an example of The Process at its worst.

Thanks a lot for this; I hope this thread comes completely to fruition and makes XFCE+systemd usable on laptops OOTB again.

[eshchenko]

Dear Developers

I have exactly the same problem - after opening the lid - notebook wakes up -
tty are ok but graphical screen is black.

Could you please comment if there is a progress!
From my side I can give you a hint.
Sometimes it helps to open/close the lid twice!

The first attempt is always unsuccessful.
Second might work.

The trick:
echo "HandleLidSwitch=ignore" | sudo tee -a /etc/systemd/logind.conf
echo "HandleLidSwitchExternalPower=ignore" | sudo tee -a /etc/systemd/logind.conf
does not work in my case...

Just now I had several successful open/close/open cycles by setting
HandleLidSwitch=suspend

My hardware is Samsung N145P
It is rather old, but nice....

Software: lightdm, xfce4.12.4, latest Linux Mint 19 64bit (all updates installed)
Light Locker settings:
Security:
Auto lock - Never
Lock screen when system is going for sleep - enabled

Best regards, Dmitry

[bikepunk]

I can reproduce the issue with xubuntu 18.04 in a Lenovo B590.