! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce4-screensaver on laptop: lid action with suspend/resume shows desktop co...
Status:
RESOLVED: MOVED
Product:
Xfce4-screensaver
Component:
General

Comments

Description Maurizio Galli 2018-10-21 09:21:25 CEST
Created attachment 8052 
Relevant systemd logs

Hello I  packaged xfce4-screensaver for openSUSE and I'm maintaining it in the following development repository: https://build.opensuse.org/package/show/X11:xfce/xfce4-screensaver

Lock-screen does not play well with Laptop Lid actions + suspend/resume:

Steps to reproduce:
1. select "Suspend" in Xfce Power Manager > General > Laptop Lid
2. select  "Lock screen when screensaver is active" in Screen Saver Preferences
3. close lid and wait for system to suspend.
4. open lid and resume system

Result:
Lock screen appears for a fraction of a second and then desktop content appears without the need of entering user's login password.
However the desktop is locked because I need to blindly type my login password before I can do anything further.


What works:
On the other end when calling suspend through the menu and then resume, the lock-screen works as expected.

I attached systemd logs for reference.
Comment 1 Yury Martynov 2018-10-25 15:30:32 CEST
Maybe resolved, but in locked mode (login dialog) i see only black background 
It can't get a color property using my configuration for `xfdesktop-4.12.4`

My config:
        <property name="workspace0" type="empty">
          <property name="color-style" type="int" value="3"/>
          <property name="image-style" type="int" value="0"/>
          <property name="last-image" type="string" value="/home/linxon/2.jpg"/>
          <property name="color1" type="array">
            <value type="uint" value="0"/>
            <value type="uint" value="5498"/>
            <value type="uint" value="13400"/>
            <value type="uint" value="65535"/>
          </property>
          <property name="backdrop-cycle-enable" type="bool" value="false"/>
          <property name="brightness" type="int" value="0"/>
          <property name="saturation" type="double" value="1.000000"/>
          <property name="color2" type="array">
            <value type="uint" value="1996"/>
            <value type="uint" value="9725"/>
            <value type="uint" value="19752"/>
            <value type="uint" value="65535"/>
          </property>
        </property>

Thank you!
Comment 2 Yury Martynov 2018-10-25 15:32:36 CEST
sorry i was wrong :(

Thread: https://bugzilla.xfce.org/show_bug.cgi?id=14769
Comment 3 Git Bot editbugs 2018-10-28 23:13:11 CET
Sean Davis referenced this bugreport in commit bd8c16e580cad3abb3f0f62c514e0a5242342dd3

Notify invalid lid-switch configuration and add Resolve button (bug #14782)

https://git.xfce.org/apps/xfce4-screensaver/commit?id=bd8c16e580cad3abb3f0f62c514e0a5242342dd3
Comment 4 Sean Davis editbugs 2018-10-28 23:14:55 CET
I was able to reproduce this on my system, and found the cause to be related to the logind-handle-lid-switch setting for Xfce Power Manager. The above commit adds some detection for this and a button to resolve the configuration error.
Comment 5 Maurizio Galli 2018-11-06 17:07:27 CET
(In reply to Sean Davis from comment #4)
> I was able to reproduce this on my system, and found the cause to be related
> to the logind-handle-lid-switch setting for Xfce Power Manager. The above
> commit adds some detection for this and a button to resolve the
> configuration error.

Thank you the issue reported is resolved however after resume from suspend, the desktop content is still visible for a second before the lock -screen appears. I will look into it and if needed open a new report.
Comment 6 Vinzenz Vietzke 2019-03-27 17:14:50 CET
(In reply to Maurizio Galli from comment #5)
> Thank you the issue reported is resolved however after resume from suspend,
> the desktop content is still visible for a second before the lock -screen
> appears. I will look into it and if needed open a new report.

This problem still exists. With xscreensaver everything is fine, but unfortunately not with xfce4-screensaver.
Therefore the bug report should be re-opened.

If you need any log files or special tests please let me know!
Comment 7 Maurizio Galli 2019-03-31 09:47:41 CEST
(In reply to Vinzenz Vietzke from comment #6)
> (In reply to Maurizio Galli from comment #5)
> > Thank you the issue reported is resolved however after resume from suspend,
> > the desktop content is still visible for a second before the lock -screen
> > appears. I will look into it and if needed open a new report.
> 
> This problem still exists. With xscreensaver everything is fine, but
> unfortunately not with xfce4-screensaver.
> Therefore the bug report should be re-opened.
> 
> If you need any log files or special tests please let me know!

I'm reopening this because I can confirm the behavior. Steps to reproduce are the same as comment #1.

If we need a new bug report please let me know.
Comment 8 haarp 2019-04-12 12:00:13 CEST
This tends to be even worse when you automatically switch monitor layouts on wakeup, as Xfce's display settings can do. There's a random chance the lockscreen will either:

- not show up at all, revealing a static image of previous screen contents
- show up partially and offset on one monitor while showing the screen contents of another
- show up fully on one monitor while showing the screen contents of another
- show up fully on one monitor while blanking the others (intended use case)

Not only does this reveal possibly private information, it also confuses the user. I can see my normal windows, when I type in my password now, will it go to the screensaver or a chat window? I rather kill the xfce4-screensaver process than risking it.
Comment 9 jorp 2019-05-18 02:37:30 CEST
Experiencing the same issue as from the described scenario in comment #1 as well.

I'm using:
a fresh install of xfce4 spin of Fedora 30 on a ThinkPad x220
xfce4-screensaver 0.1.4
patched version of xflock4 that contains: `"xfce4-screensaver-command --lock" \`
I've also uninstalled the default locker, xscreensaver

Please let me know if I can be of anymore assistance
Comment 10 Vinzenz Vietzke 2019-05-29 11:12:04 CEST
I just got pointed to disable fading in xscreensaver. This solves the similar problem there. Maybe this is something to help with xfce4-screensaver as well?
Comment 11 Sean Davis editbugs 2019-06-05 11:50:19 CEST
Looking into this now... Are any of you using ConsoleKit? It looks like the PrepareForSleep signal was only added to the Systemd portion of the code.
Comment 13 Sean Davis editbugs 2019-06-05 12:18:48 CEST
I just added some debug code for the PrepareForSleep signal.

https://git.xfce.org/apps/xfce4-screensaver/commit/?id=b35b5c07c72f54b5550b5b24231fa37b3c3ff5eb

If you run `xfce4-screensaver --debug`, then close your laptop lid, you should see the following message:
Handling Logind PrepareForSleep

If this message is not seen, xfce4-power-manager is not configured to listen for lid events and there should be a blue info bar in the Screensaver preferences that says:
Xfce Power Manager is not configured to handle laptop lid events

This has a resolve button that should correct the setting by setting:
/xfce4-power-manager/logind-handle-lid-switch

to False
Comment 14 Maurizio Galli 2019-06-05 12:59:48 CEST
Created attachment 8618 
xfce4-screensaver --debug log
Comment 15 Maurizio Galli 2019-06-05 13:00:30 CEST
Sean enabling ConsoleKit might have solved the issue. Need further test tho and I attached the --debug log
Comment 16 Michael Weiser 2019-09-15 02:42:26 CEST
Created attachment 9025 
Add systemd sleep inhibitor

Looking at the timestamps in debug output it seems to me that systemd is simply suspending too fast for xfce4-screensaver to activate the lock screen. Indeed according to debug messages handling of PrepareForSleep happens only after resume:

# src/xfce4-screensaver --debug --no-daemon
[gs_debug_init] gs-debug.c:115 (02:22:43.147):	 Debugging enabled
[main] xfce4-screensaver.c:97 (02:22:43.147):	 Initializing xfce4-screensaver 0.1.8
[init_session_id] gs-listener-dbus.c:2039 (02:22:43.153):	 Got session-id: /org/freedesktop/login1/session/_34
[gs_listener_x11_set_timeouts] gs-listener-x11.c:312 (02:22:43.153):	 Saver timeout updated to 300 seconds
[gs_listener_x11_set_timeouts] gs-listener-x11.c:318 (02:22:43.153):	 Lock timeout updated to 60 seconds
[gs_listener_x11_acquire] gs-listener-x11.c:288 (02:22:43.154):	 ScreenSaver Registered
<Lid close>
<System asleep for about 7 seconds>
<Lid open>
<Desktop visible for about 1 second>
[listener_dbus_handle_system_message] gs-listener-dbus.c:1361 (02:22:52.025):	 Handling Logind PrepareForSleep
[listener_dbus_handle_system_message] gs-listener-dbus.c:1367 (02:22:52.025):	 Logind requested session lock
[gs_grab_grab_root] gs-grab-x11.c:347 (02:22:52.025):	 Grabbing the root window
<Lock screen is activated>

Adding a sleep delay inhibitor lock[1] makes the problem go away since it gives xfce4-screensaver time to activate the lock screen before allowing systemd to continue suspending the system:

# src/xfce4-screensaver --debug --no-daemon
[gs_debug_init] gs-debug.c:115 (02:27:23.132):	 Debugging enabled
[main] xfce4-screensaver.c:97 (02:27:23.132):	 Initializing xfce4-screensaver 0.1.8
[init_session_id] gs-listener-dbus.c:2116 (02:27:23.137):	 Got session-id: /org/freedesktop/login1/session/_34
[gs_listener_init] gs-listener-dbus.c:2142 (02:27:23.137):	 Acquiring logind sleep inhibitor lock
[gs_listener_x11_set_timeouts] gs-listener-x11.c:312 (02:27:23.139):	 Saver timeout updated to 300 seconds
[gs_listener_x11_set_timeouts] gs-listener-x11.c:318 (02:27:23.139):	 Lock timeout updated to 60 seconds
[gs_listener_x11_acquire] gs-listener-x11.c:288 (02:27:23.140):	 ScreenSaver Registered
<Lid close>
[listener_dbus_handle_system_message] gs-listener-dbus.c:1432 (02:27:28.585):	 Handling Logind PrepareForSleep
[listener_dbus_handle_system_message] gs-listener-dbus.c:1438 (02:27:28.585):	 Logind requested session lock
[gs_grab_grab_root] gs-grab-x11.c:347 (02:27:28.585):	 Grabbing the root window
[...]
<System asleep for about 7 seconds>
<Lid open>
<Lock screen immediately present>
[listener_dbus_handle_system_message] gs-listener-dbus.c:1432 (02:27:36.807):	 Handling Logind PrepareForSleep
[listener_dbus_handle_system_message] gs-listener-dbus.c:1447 (02:27:36.807):	 Reinstating logind sleep inhibitor lock
[listener_dbus_handle_system_message] gs-listener-dbus.c:1450 (02:27:36.810):	 Logind requested session unlock

The attached patch is tested with systemd 243rc2 and xfce4-screensaver git HEAD (github mirror) and 0.1.8 release. A quick read of ConsoleKit docs suggests they have a similar interface for the same reason so that it should work with CK as well.

[1] https://www.freedesktop.org/wiki/Software/systemd/inhibit/#takingdelaylocks
Comment 17 Michael Weiser 2019-09-15 09:23:12 CEST
Sorry, somehow managed to attach above path to the wrong report (maybe relevant here as well though). https://bugzilla.xfce.org/show_bug.cgi?id=15929 (on 'suspend' : locking only occurs after resume, desktop is visible (with workaround)) is what I'm actually trying to fix. Attach again in this other bug?
Comment 18 haarp 2019-12-04 09:03:28 CET
*** Bug 15763 has been marked as a duplicate of this bug. ***
Comment 19 haarp 2019-12-04 09:36:33 CET
Issues with blanking/dialog handling with multiple monitors and/or changing monitor layouts after plug/unplug, suspend, etc. seem to be common in xfce4-screensaver. Also see bug 15763, bug 15925, bug 16090. I think it's best to keep them all collected in this bug report to avoid duplicates.

From personal experience and what I've seen others complain about, these problems exist:

- Screensaver won't show up at all, revealing static image of previous screen contents
- Screensaver shows up, but with a delay, briefly revealing screen contents
- Screensaver shows up partially and/or offset on one monitor, while showing the screen contents of other monitors
- Screensaver shows up on only one monitor, without capturing the mouse, leaving other monitors to be partially interacted with! (bug 15763)
- Password dialog won't show up (but actually exists and has keyboard focus)
- Password dialog shows up but is frozen (but has keyboard focus)
- Password dialog shows up properly, and stays visible while a monitor is (un)plugged, but will not show up again after being allowed to time out and brought up again

All of these problems appear related to monitor events. A single-monitor or multi-monitor setup that doesn't change its monitor layout appears unaffected. However the layout can change by (un)plugging monitors, opening/closing the laptop lid or suspending/hibernating the machine. Thus they can be frequent events, leading xfce4-screensaver to frequently fail (hence the number of related bug reports).

Apart from being a nuisance, these issues have serious security implications. A screenlocker that doesn't lock the screen or a password dialog that is invisible and entices users to blindly type their password in (not knowing if the dialog or a chat window underneath receives it) is bad. I would even suggest to elevate this bug report's severity setting.

Please, someone have a look at this. I want to like and use this screensaver, but this bug is a showstopper.
Comment 20 Sean Davis editbugs 2020-01-15 11:47:58 CET
This may very well be resolved with Michael's patch on https://bugzilla.xfce.org/show_bug.cgi?id=15929. This has been applied to master, so please check it out.
Comment 21 haarp 2020-01-16 20:35:50 CET
(In reply to Sean Davis from comment #20)
> This may very well be resolved with Michael's patch on
> https://bugzilla.xfce.org/show_bug.cgi?id=15929. This has been applied to
> master, so please check it out.

Hello Sean,

with this patch applied, the screensaver becomes a bit more deterministic around suspending (or I could be imagining things). There is still some sort of race condition present however. For this I did some tests.

xfce4-screensaver 0.1.8
Laptop with output: 1920x1080
External monitor with output 3440x1440, primary, right-of laptop output
Procedure:
- Start fresh xfce4-screensaver
- Move mouse to right screen
- Suspend
- Unplug external monitor
- Wake machine back up
- Observe

I have determined 3 possible outcomes. I'll post them here, including debug logs, now.
Comment 22 haarp 2020-01-16 20:37:17 CET
Created attachment 9388 
Good log

When waking up, the screensaver shows the unlock dialog on the laptop screen. Good boy!

Doesn't happen often tho. :(
Comment 23 haarp 2020-01-16 20:39:51 CET
Created attachment 9389 
Bad log

When waking up, the laptop screen remains black. There is an unlock dialog somewhere off the edge of the screen which has keyboard focus. Can be unlocked by typing blindly into it.
Comment 24 haarp 2020-01-16 20:43:40 CET
Created attachment 9390 
Worst log

Upon waking up, the screen is black. There is no unlock dialog and unlock is impossible. X is stuck using 100% CPU. A VT switch is impossible (even chvt on a ssh session blocks!)

Killing the screensaver at this point has no effect. X needs to be SIGKILLED to regain control of the machine.

I strongly suspect that this line is an indicator of what went wrong:

(xfce4-screensaver:4519): Gdk-WARNING **: 20:04:14.454: Native Windows wider or taller than 32767 pixels are not supported
Comment 25 Sean Davis editbugs 2020-01-23 01:57:31 CET
I think I've identified the issues and have some patches I'm testing now. It's related to an old GDK bug that we once worked around, but was removed during some cleanup.
Comment 26 haarp 2020-02-08 17:37:03 CET
Hey Sean, any news on those patches? Cheers!
Comment 27 martin.babutzka 2020-02-09 22:00:55 CET
Can confirm this bug. I hope the fixes are successful. Could this be also related to the xfce-screensafer server crashing occassionally? Compare bug https://bugzilla.xfce.org/show_bug.cgi?id=15633
Comment 28 Sean Davis editbugs 2020-03-23 00:54:02 CET
Please test this with the latest git master or the soon-to-be-released 0.1.9 release.
Comment 29 Maurizio Galli 2020-03-23 03:46:43 CET
(In reply to Sean Davis from comment #28)
> Please test this with the latest git master or the soon-to-be-released 0.1.9
> release.

With 0.1.9, the desktop still shows for a split second before the lockscreen
Comment 30 Maurizio Galli 2020-04-01 08:43:28 CEST
Still happening with xfce4-screensaver 0.1.9 and xfce4-session 4.14.2.

on resume, desktop content is loaded before the lockscreen
Comment 31 Alexander Butenko 2020-04-04 16:53:47 CEST
@haarp, can you please retest with 0.1.10 release in the same way? On my laptop i see that all the problems seems fixed

as a second run, please try with the following patch 

diff --git a/src/gs-listener-dbus.c b/src/gs-listener-dbus.c
index 6307324..44d2643 100644
--- a/src/gs-listener-dbus.c
+++ b/src/gs-listener-dbus.c
@@ -562,6 +562,7 @@ remove_sleep_inhibit (GSListener *listener) {
         return;
     }
 
+    gs_debug ("Releasing sleep inhibitor");
     if (close(listener->priv->sleep_inhibitor) < 0) {
         gs_debug ("Can't close file descriptor");
         return;
@@ -1508,8 +1509,7 @@ listener_dbus_handle_system_message (DBusConnection *connection,
                     gs_debug ("Logind requested session lock");
                     g_signal_emit (listener, signals[LOCK], 0);
 
-                    gs_debug ("Releasing sleep inhibitor");
-                    remove_sleep_inhibit (listener);
+                    g_timeout_add (1000, (GSourceFunc) remove_sleep_inhibit, listener);
                 } else {
                     gs_debug ("Logind requested session lock, but lock on suspend is disabled");
                 }
Comment 32 Bernard 2020-05-06 15:39:09 CEST
Did you push any update to the Ubuntu 20.04 repositories? I have the same issue in ubuntu, but the help screen doesn't show the last digit of the XFce version (only 14.4).

In this version (so not the xubuntu, but the stand alone version), through the menu next to the clock, if I choose "Lock Screen", nothing happens. If I resume from suspend, I don't need to log in.
Comment 33 Git Bot editbugs 2020-05-25 22:24:05 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/1.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #14782

Reported by:
Maurizio Galli
Reported on: 2018-10-21
Last modified on: 2020-05-25
Duplicates (1):
  • 15763 xfce4-screensaver not locking all monitors

People

Assignee:
Sean Davis
CC List:
12 users

Version

Attachments

Relevant systemd logs (4.78 KB, text/plain)
2018-10-21 09:21 CEST , Maurizio Galli
no flags
xfce4-screensaver --debug log (28.15 KB, text/plain)
2019-06-05 12:59 CEST , Maurizio Galli
no flags
Add systemd sleep inhibitor (4.53 KB, patch)
2019-09-15 02:42 CEST , Michael Weiser
no flags
Good log (31.57 KB, text/plain)
2020-01-16 20:37 CET , haarp
no flags
Bad log (30.06 KB, text/plain)
2020-01-16 20:39 CET , haarp
no flags
Worst log (22.40 KB, text/plain)
2020-01-16 20:43 CET , haarp
no flags

Additional information