On Debian and, by extension, Ubuntu, when suspending a laptop via closing the lid on XFCE, the screen stays black after resuming from suspend. The only way to "fix" the system is to blindly type "xrandr --auto" into a terminal or switch to a TTY and restart X.

This issue can be easily fixed by disabling Upower support when the package is compiled. However, despite being set as default in 4.16, Debian seems to have it re-enabled. Removing "--enable-upower-glib" from the configure flags in the package instantly solves this issue.

On Mon, 2 Aug 2021 02:08:09 +0200 (CEST) truetechie@tutanota.com wrote:
 > Package: xfce4-settings
 > Version: 4.16.0-1
 > Severity: critical
 >

 > On Debian and, by extension, Ubuntu, when suspending a laptop via
closing the lid on XFCE, the screen stays black after resuming from
suspend. The only way to "fix" the system is to blindly type "xrandr
--auto" into a terminal or switch to a TTY and restart X.

As an xfce user, I haven't experienced this problem. What graphics
hardware and kernel are you seeing this with? Is this on battery or when
plugged in? Are you using light-locker (and if so, what version)? Do you
have upower installed (and if so, what version)? What is xfce4
configured to do on a lid close (xfconf-query --verbose --list -c
xfce4-power-manager)?

This is on the 5.10.0-8 kernel on Debian Bullseye with Nvidia graphics with the proprietary driver installed. I am using light-locker 1.8.0 and upower 0.99.11-2 with the desktop configured to suspend my computer on lid closures. This happens whether or not the laptop is plugged in and is a confirmed bug upstream with how the upower support is implemented.

Aug 3, 2021, 05:28 by dilinger@queued.net:

Thank you!


This appears to be reported upstream at
https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222 , which was
fixed (and merged) with
https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/20 in a
somewhat unsatisfying way.

It's up to the debian xfce4 maintainers to determine if there's value in
leaving upower enabled for xfce4-settings in bullseye, and/or this bug
should be reassigned or cloned to upower.

Control: severity -1 normal
Hi Elliot,

thanks for the message, but it's usually best to directly send messages to the
bug report, that way it's archived on the bug tracker (sorry we didn't reply
earlier on it).

That's definitely not a “critical” bug though (thus adjusting the severity).
And unfortunately the “upstream” fix isn't really good because that actually
means just not listening to the lid events, and that's a behavior which I
think we do want.

As far as I can tell it does work fine on other configurations, but maybe
there's an issue with the proprietary NVidia driver (if you can try with
nouveau or something like that, it'd be an interesting data point).

Regards,

I have the same issue for months.
Here are my details, tell me if you need more:

Lenovo Thinkpad X390
Buster amd64 with 5.10.46-2~bpo10+1 kernel
xfce 4.12.5
light-locker 1.8.0-3
upower 0.99.10-1
Intel UHD Graphics 620 (i915 driver)

NB:
* My laptop is configured to lock screen when the lid is closed but I use suspend to RAM manually (from the Xfce panel) anyway before closure.
* My workaround is to close the lid one more time, and reopen it less than 1 minute after. The screen comes to life again that way. Of course, I would prefer not having the issue at all :)

HIH

I have also had the same issue consistently. Happens occasionally, but is
quite annoying. I can fix it by switching to a virtual terminal (which
works), scheduling "DISPLAY=:0 xrandr --auto" to run in the near future,
and then switching back to the X VT, and waiting for the command to run.

My stats:

OS: Debian GNU/Linux 11 (bullseye)
Hardware: Lenovo Thinkpad T460s
Graphics: Intel Corporation Skylake GT2 [HD Graphics 520]
Kernel: 5.10.0-9-amd64 (with i915 driver)
Packages: xfce4 4.16
Packages: upower 0.99.11-2
Packages: light-locker 1.8.0-3

Cheers,
- Chris

Greetings to you in the name of the Lord. My name is Mrs Amaib Chi. There
is something very important I want to discuss with you. I'm a very
influential and wealthy woman but I'm sick and dying.


I'm suffering from severe malignancy and have a few months to live. I send
you this message because I want to make a charity donation to the Charity
in your country.

Please, endeavour to get back to me for more details, thanks and May God
bless.


Warm regards

Mrs Amaib Chi

Hello,

I'm having the same bug. Me too I have to switch to the console with Ctrl-Alt-F1 to revive the graphical console. I found that the following is sufficient to revive the display from the blank screen:

chvt 7; DISPLAY=:0 xrandr --auto

The second part of the workaround was found in the logs of this bug, but the first part is easier than the previously proposed hack: delaying the xrandr and manually switching to the vt 7.

My settings:

$ dpkg -l xfce4 upower light-locker nvidia-kernel-dkms|grep ii; uname -a; lspci |grep -i nvidia
ii  light-locker       1.8.0-3      amd64        simple screen locker for lightDM display manager
ii  nvidia-kernel-dkms 470.141.03-1 amd64        NVIDIA binary kernel module DKMS source
ii  upower             0.99.20-1    amd64        abstraction for power management
ii  xfce4              4.16         all          Meta-package for the Xfce Lightweight Desktop Environment
Linux cafuron 5.18.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10) x86_64 GNU/Linux
01:00.0 3D controller: NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] (rev a1)

Thanks,

This bug also causes the desktop to be accessible for a split second
before the lock screen kicks in when resuming from suspend, c.f
https://askubuntu.com/questions/1383379/xubuntu-desktop-visible-after-suspend-before-lock-screen/

I know disabling upower-glib support was frowned upon in the past but
modern upower does not handle suspend/resume or lid events (that
happens via other systemd components now) and xfce4-settings doesn't
need upower for xfce4-power-manager to work properly.

Recompiling wihtout upower-glib closes what is essentially a security
bug, since the expectation is that resumed systems are locked, and this
problem presents a second or two of unrestricted access to the desktop
before locking kicks in.

I've tested this on a Thinkpad X1 Yoga Titanium and a Thinkpad X1 Yoga
Generation 3 (both with Intel graphics) and a Dell Precision 7820 with
an AMD WX 5100 card, so I don't think it's nVIDIA specific.

Please reconsider --enable-upower-glib.

Thanks,
khm