xscreensaver is being used for locking and it's set to lock on system sleep event
system is suspended by closing the laptop lid
After the system is resumed, I'm presented with the static frozen screenshot of my desktop instead of the screensaver. But typing my password and pressing "ENTER" causes the desktop to unfreeze, i.e. keyboard input went to xscreensaver, and xscreensaver unlocks the desktop. This means that the foreground window which grabbed keyboard input was in fact the xscreensaver lock screen, but for some reason it was not rendered properly on the screen (basically, xscreensaver lock screen was invisible).
If desktop compositing is disabled then everything works as expected, i.e. no desktop freeze after system resume, xscreensaver shows its lock screen as it's supposed to be. This is why I believe it might be an issue with the desktop composition.
Also, the issue is not limited only to the xscreensaver. I verified that there is the same issue if using gnome-screensaver.
Looks like it's specifically "Display fullscreen overlay windows directly" causing this. I've turned that off and haven't encountered it again (I'm also using xscreensaver).
Another possible workaround:
It looks like after connecting and disconnecting the external HDMI monitor the issue does not occur (until the next reboot).
Usually, I get a frozen screen for 15-30 seconds, then it might update for s fraction of a second and freeze again for another 15-30 seconds. I.e. it does not unfreeze completely.
Hi everybody,
I'm not familiar with Gitlab, I can't code and I never reported bugs to any project... my English is far from good. Please excuse me, I hope this is the right place to post this information.
I believe my system is affected by this bug too, using Xfce 4.18 on Debian 12 (now stable).
When I close the lid of my laptop it automatically locks the screen. When I open the lid I can see the desktop but everything is frozen, so I blindly type my password and press "Enter" and everything returns to work properly.
Turning off "Display fullscreen overlay windows directly" had no effect for me.
I found varius bug reports for this kind of behavior and seems to be related to xfwm4, indeed by turning vblank_mode to "off" (or disabling compositing) fixes this (for me). By doing this however I get video "tearing" (e.g. when playing youtube videos in high resolution in Firefox or movies in VLC...)
So I switched back to vblank_mode = "glx" and tried to configure Xorg. I created /etc/X11/xorg.conf with just a few lines to specify the driver:
Then restarted lightdm and everything seems to work now (I always see Xscreensaver when resuming from suspend and I don't see video tearing playing videos). Lightdm is also loading the login screen much faster than before (e.g. when switching user), I don't know why...
Software and system details:
Lenovo IdeaPad
Intel 11th gen. Core i5 with "Iris Xe" Graphics
Debian 12 aka "bookworm" (stable)
Xfce 4.18
xfwm 4.18.0
xscreensaver 6.06 (in "Blank screen only" mode)
UPower 0.99.20
Many thanks for your reply, I'm very grateful to all developers and contributors of Xfce!
After reading further I found that "intel" Xorg driver is deprecated, so it is not a good solution, should keep "modesetting" driver instead.
As mentioned before, I had already disabled "Display fullscreen overlay windows directly" in xfwm4-tweaks-settings with no effect even after logout or "xfwm4 --replace".
To be honest I installed GNOME desktop a few months ago (not because of this problem) so I have no Xfce environment to test right now...
I have the same problem, if I'm closing the lid and the system will be locked. Important: My system is not suspended or locked, when the lid is closed. I have other mechanisms to lock the system after X minutes, but I can reproduce this issue very easy.
I'm on Debian Testing (Trixie) with xfwm4 version 4.18.0[1] and the compositor is enabled. I use i3lock as a locker and disabled all other locker tools, e.g. light-locker. I don't have any screensaver installed and the only thing I have configured via xfce Power Manager to put the monitor to sleep after 5 minutes of inactivity and to switch off the display, when the laptop lid is closed.
If I lock the system with the lid open or my laptop is connected to a docking station with external monitors, everything works. I see the i3lock screen and can visible unlock it.
If the lid is closed for a while and the system is locked after a certain time, then I have the here described "frozen screen / invisible unlock prompt" issue, after opening the lid. I see the last screen output from before closing the lid and I can invisible unlock my system.
This problem does not occur if the compositor is deactivated. Only disabling Display fullscreen overlay windows directly don't change anything.
It's very easy for me to reproduce this, e.g.:
$ sleep 10s; i3lock --color 396a7d -f -e
Closing the lid during the 10 seconds and open it again after the 10 seconds, the screen is locked, but I can't see the i3lock screen. Instead I see the very same before closing the lid (in this case my terminal) and I can blindly unlock it.
Fun fact: If my laptop is closed, connected to the docking station and locked, opening the lid shows the lock screen on my laptop monitor, too, hence the issue is not present.
When you close the lid of your laptop in that situation, does the hardware/kernel/something shut off the laptop panel output? If so, that would make more sense. Otherwise I don't really get it; if the display is still on, there should be no drawing-related difference between the lid open or closed.
Closing the lid is shutting off the laptop display. I think this is coming from this option here:
If I close the lid for, e.g. 4 minutes, the display is off during that time. Opening the lid will power on the laptop display again and I can continue my work without unlocking my system, because it was never locked (this is intentional).
Only if my lid is closed for 15 minutes, i3lock (or to the be precise: xautolock), will lock my system and then I ran in this issue here.
Argh, there's no "do nothing" setting for that option... was really curious to know what happens when closing the lid doesn't turn off the display. I'm assuming/hoping that this issue wouldn't occur in that case.
So anyway, I suspect this fits with all the other cases here. Suspend has nothing to do with it; the issue is monitors disappearing and reappearing, and xfwm4's compositor not handling something properly when that happens. (Or, worse, the X server, possibly in the XCOMPOSITE extension code, not handling something properly.)
As a general question to everyone (including myself): can we repro this with another compositing manager? Perhaps xfwm4 with the compositor turned off, plus xcompmgr or picom? If we can, then this is an X server issue. If not, it's xfwm4.