Screen is not always truly locked upon wake from sleep under Wayland

[ArrayBolt3]

OS: Arch Linux LXQt version: 2.2.0 Qt version: 6.10.0

When putting the system into suspend (by closing the lid or clicking on Fancy Menu > Leave > Suspend), the system may enter suspend before the screen is locked, depending on how long it takes for the screen locker to activate. Generally the screen is locked before sleep is triggered if just executing swaylock directly, but Kicksecure's lock-screen script does not execute fast enough for the screen to lock first.

Steps to reproduce:

• Install Arch Linux with LXQt, labwc, and swaylock.
• Log into an LXQt (Wayland) session.
• Set the compositor to labwc.
• Log into an LXQt (Wayland) session again.
• Create a file at /usr/bin/lock-screen with the following contents:

#!/bin/bash
sleep 5
swaylock

• Set /usr/bin/lock-screen as executable.
• Open Fancy Menu > LXQt Configuration Center > Session Settings > Wayland Settings (Experimental), and set Screenlock command to /usr/bin/lock-screen.
• Click Close, then log out and log back in.
• Put the system into sleep (Fancy Menu > Leave > Suspend). It will probably pause for a long time, and end up locking before sleep.
• Wake the system from sleep and unlock it.
• Put the system into sleep (Fancy Menu > Leave > Suspend) again. This time it will almost immediately suspend while the screen is still unlocked.
• Wake the system from sleep. It will be unlocked for around four seconds, then the screen locker will kick in.

I think this is happening because ScreenSaver::lockScreen() runs the screen locker command asynchronously. lxqt-session calls this function before going into sleep, so the screen locker and the process of putting the system to sleep end up racing each other.

Some screen lockers, like Swaylock, support sending a notification to the caller once the screen is fully locked:

-R, --ready-fd <fd>
    File descriptor to send readiness notifications to.

    When the session has been locked, a single newline is written to the FD.
    At this point, the compositor guarantees that no security sensitive content
    is visible on-screen.

It might be possible to integrate with features such as these if they are available; this could obviously vary from locker to locker, so it may require special support like LXQt has for individual Wayland compositors. A user-configurable "time to wait after locking screen before entering sleep" would also be useful for lockers that just don't offer any such notifications.

[stefonarch]

Maybe I'm missing something, but for that we have the delay setting here:

[ArrayBolt3]

@stefonarch I missed that setting, that does look like what I was suggesting implementing. Having it in session settings is rather unintuitive though, it seems to me like users would probably find this a lot easier if it were in lxqt-config-powermanagement instead. But that's an unrelated issue.

A delay like this is nice for users who are able to tune the delay based on how fast their machine is, but I think it would still be useful to have integration with screen lockers that provide lock notifications. One second (or two, or five, etc.) might be more than enough for the lock screen to activate on a distro developer's system, but be less than enough for a user running a Core 2 Duo. (FWIW the Arch system I tested on has the timeout set to 0 ms I see, so this was basically "worst case scenario". But this is also the default configuration of Arch, so it's probably a pretty common scenario.)

[stefonarch]

Default is 0 afaik and yes: it needs always at least 1250ms (my experience), so probably we should choose another default like 1,5sec.

Didn't know about that signal and waiting for it would be nice. It looks only swaylock does have that atm and it needs to be run with arguments, which makes everything quite complicated.