When using `fade-in`, suspending the laptop shows screen contents

[luispabon]

Given the config below with a 0.2s fade in, when I suspend my laptop the animation doesn't complete before the laptop actually goes into sleep. I'm not entirely sure how to avoid this. The animation completes after the laptop resumes from suspension.

The main take away here is that screen contents aren't obfuscated and are visible for a few seconds after resuming.

Vid: https://www.youtube.com/watch?v=pBpErmBESo4

Sway config:

exec swayidle -w \
         timeout 300 'swaylock -f -c 000000 -i $lock_bg' \
         timeout 600 'swaymsg "output * dpms off"' \
              resume 'swaymsg "output * dpms on"' \
         before-sleep 'swaylock -f -c 000000 -i $lock_bg'

Swaylock-effects config:

ignore-empty-password
font=Ubuntu

clock
timestr=%R
datestr=%a, %e of %B

screenshots

fade-in=0.2

effect-blur=30x2
effect-greyscale
effect-scale=0.1

indicator
indicator-radius=240
indicator-thickness=20
indicator-caps-lock

key-hl-color=880033

separator-color=00000000

inside-color=00000099
inside-clear-color=ffd20400
inside-caps-lock-color=009ddc00
inside-ver-color=d9d8d800
inside-wrong-color=ee2e2400

ring-color=231f20D9
ring-clear-color=231f20D9
ring-caps-lock-color=231f20D9
ring-ver-color=231f20D9
ring-wrong-color=231f20D9

line-color=00000000
line-clear-color=ffd204FF
line-caps-lock-color=009ddcFF
line-ver-color=d9d8d8FF
line-wrong-color=ee2e24FF

text-clear-color=ffd20400
text-ver-color=d9d8d800
text-wrong-color=ee2e2400

bs-hl-color=ee2e24FF
caps-lock-key-hl-color=ffd204FF
caps-lock-bs-hl-color=ee2e24FF
disable-caps-lock-text
text-caps-lock-color=009ddc

[mortie]

Ah, yeah. When -f is used, the original process forks and exits once it has created the window; when --fade-in is used, the window is initially created with the image without effects applied. That means it creates the window with all content still visible, then the system is suspended before the animation gets time to complete.

For the time being, you can fix this in one of two ways:

1. Disable fade-in on suspend; change the before-sleep command to swaylock -f -c 000000 -i $lock_bg --fade-in 0. This will override the config file's fade-in=0.2.
2. Add a delay; change the before-sleep command to swaylock -f -c 000000 -i $lock_bg; sleep 1.

The eventual solution will be for me to change the logic of when forking happens to be after the fade animation is complete.

[luispabon]

Thank you, I've disabled fading on suspend for now as suggested. You want me to keep this open to track any future fixes to it?

[mortie]

Yeah sure, let's keep this issue opened until it's fixed :)

[luispabon]

:ok_hand:

[Zocker1999NET]

@luispabon Maybe this could help you, I worked around this issue I've written this this script. The script is free to use. It allows enabling or disabling fade-in (or grace, which can be more fatal) very easy depending on why the screen will be locked.

Also it disables a running fade-in by killing the old swaylock process and launching another one. I'm using this to prevent a running grace period and fade-in after resuming from sleep.

[luispabon]

Cheers @Zocker1999NET for the workaround :+1:

[mortie]

Ok, so after https://github.com/mortie/swaylock-effects/commit/03bbbd3ad1be9fb1dda567678a61862e24c0bb37, this issue should be resolved. With -f, the parent process should now only exit once the fade-in is done.

[abinlatheef]

Is there a way to use this from the config itself, that is, not entering that as a flag?