Sway: After resuming from suspend: desktop briefly shows up before lockscreen

[camoz]

• Sway version: 1.0-beta.1-174-g80a1c340 (Nov 11 2018, branch 'master')
• Debug log: https://ptpb.pw/lDoA
• Config file: https://ptpb.pw/nAMb
  The config file is the default one with just the swayidle example commented in, plus different $mod and $term.

Steps to reproduce

Start sway, open terminal and issue 'systemctl suspend', press key for resume.
What happens: I see my desktop for 0.6 seconds, then I see the lockscreen.
What should happen: I see the lockscreen.

Unlocking works fine btw.
This is on a Samsung Chromebook Plus, running ArchlinuxARM: Linux alarm 4.19.1-2-ARCH #1 SMP Sun Nov 4 19:18:32 MST 2018 aarch64 GNU/Linux

[emersion]

This is a consequence of "waiting some time in swayidle and hoping swaylock has had time to startup".

Instead we should use swaylock -f and make swayidle wait for the process to exit.

[progandy]

On the xorg/systemd side, xss-lock has the ability to transfer the (e)logind delay lock with an environment variable to the locker which allows the locker to signal readiness without forking. That is useful to keep xss-lock from spawning a second locker in case of suspending an already locked session. It also makes killing the locker in reaction to an (e)logind unlock signal possible. I don't know if this would be useful or desired for swayidle.

 -l, --tranfer-sleep-lock

    Allow the locker process to inherit the file descriptor that represents the delay lock obtained from the login manager.
The corresponding index will be made available in the environment variable $XSS_SLEEP_LOCK_FD; 
this will only be set if the reason for locking is that the system is preparing to go to sleep.
The locker should close this file descriptor to indicate it is ready.

[ddevault]

Instead we should use swaylock -f and make swayidle wait for the process to exit.

This

[m-khvoinitsky]

This is a consequence of "waiting some time in swayidle and hoping swaylock has had time to startup".

I doubt it. I experience the same issue despite I always manually lock screen before closing laptop lid and hence putting it to sleep.

It's interesting that I have experienced exactly the same issue using i3 with i3lock, again, always manually locking the screen before putting laptop to sleep.

[emersion]

I doubt it. I experience the same issue despite I always manually lock screen before closing laptop lid and hence putting it to sleep.

Do you mean you lock your screen, swaylock shows up, and when you resume your desktop shows up without swaylock? That sounds very weird.

[emersion]

It's interesting that I have experienced exactly the same issue using i3 with i3lock, again, always manually locking the screen before putting laptop to sleep.

BTH I think your issue is separate and related to your local configuration/hardware. I don't think we can do anything about it.

[m-khvoinitsky]

Do you mean you lock your screen, swaylock shows up, and when you resume your desktop shows up without swaylock? That sounds very weird.

Yes, exactly.

[m-khvoinitsky]

@camoz, can you clarify whether the issue is still reproducing if you lock your screen manually before putting laptop into sleep?

[camoz]

I was not able to reproduce it via manually locking my screen, BUT I'm barely able to reproduce it again at all. Unfortunately, I updated to a newer revision, and out of 20 times only one time I saw my desktop before the lockscreen again. I'm also not able to downgrade at the moment, sorry.

[johnae]

I have this problem very often. I tend to just close the lid on my laptop (relying on HandleLidSwitch of systemd). When I later wake it up, the desktop briefly shows - sometimes seemingly for a whole second - before the lock screen hides it.

[e00E]

I encounter this every time I systemctl suspend with sway version 1.0-beta.2-56-g00d97cb1 (Dec 24 2018, branch 'master').

The desktop should not be shown because it violates my expectation that the lock screen makes it impossible to interact with or gather information about the locked session without authenticating first.

[emersion]

Maybe fixed by https://github.com/swaywm/sway/pull/3381?

[e00E]

@emersion Yes #3381 fixes it for me.

[camoz]

I can no longer reproduce this issue with master.

[camoz]

Just experienced this issue again on my X200 with one external VGA monitor connected. The desktop showed briefly after resumung from a suspend (10 hours) on my X200 like described in my OP. With subsequent suspends afterwards, I wasn't able to reproduce it.
Version:
$ swaymsg -v swaymsg version 1.0-rc1 (Feb 3 2019, branch 'master')

[emersion]

Are you using swayidle -w and swaylock -f?

[camoz]

No, I missed those options - sorry!

[camoz]

It just happened again, exactly as described in my previous post: https://github.com/swaywm/sway/issues/3119#issuecomment-462125049

Version: swaymsg version 1.0
Arch packages from community:
local/sway 1.0-6
local/swayidle 1.2-2
local/swaylock 1.3-3

Here's the relevant part of my config section:
https://gist.github.com/camoz/9f59097edb6aece2218c4554ccba3b3c

What can I do to help? Try to obtain a debug log?

Also, should I open a new issue for swaylock / swayidle, or is this still the appropriate place for this bug?

[tokyovigilante]

I was still reliably getting this issue on my desktop (X299, Radeon VII w/ mesa drivers) until I uncommented InhibitDelayMaxSec=5 in /etc/systemd/logind.conf. Now I'm getting reliable screen locking on suspend with no desktop flash before the lock screen is displayed.

Relevant sway config:

exec swayidle -w \
    timeout 120 'swaylock -f -c 000000' \
    timeout 240 'swaymsg "output * dpms off"' \
       resume 'swaymsg "output * dpms on"' \
    before-sleep 'swaylock -f -c 000000'

[emersion]

Your first swaylock idle command is missing -f.

[tokyovigilante]

Thanks! Amended.

[camoz]

Just happened again, like described in https://github.com/swaywm/sway/issues/3119#issuecomment-475897347

Is there any reason to not re-open this?

What can I do to help? Try to obtain a debug log?

Also, what @tokyovigilante wrote doesn't make any sense, since InhibitDelayMaxSec=5 compiled into systemd by default.

[noam09]

@camoz, are you still experiencing this issue? I'm still experiencing this issue as described by @m-khvoinitsky here.
If not, what did you end up changing to resolve it?

[camoz]

@noam09 Sadly I'm not using the machine I was experiencing the issues with anymore. It had other graphical quirks (sudden black screens), which got too annoying. (Not sure if these issues are related to sway.) I'm on an old x86 laptop now, without the issue described in my OP.