Closed hengtseChou closed 6 days ago
Hey, it's not a glitch, it's niri's locked session background. It shows up because niri doesn't wait for the lock screen to present a surface before drawing the locked session. This is tracked as part of #119.
With hyprlock specifically, there's an extra problem that it animates from transparency, so niri's red locked session background shows up during the animation. Sway seems to use a black background under lock surfaces so you don't notice it there. I'm not sure if the protocol mandates using a black background in this case.
My approach to this is to use a script calling do-screen-transition before the lock screen command:
#!/usr/bin/env fish
niri msg action do-screen-transition --delay-ms 300
swaylock -f
To bind a script in your niri config, using the spawn
action:
binds {
Mod+T { spawn "~/scripts/do-something.sh"; }
}
@lpnh Appreciate the workaround!
@YaLTeR Thanks for the clarification 😌
Ah yeah, the screen transition workaround, thanks!
I am trying to pick a locking utility for the niri setup. However, with swaylock and hyprlock, they glitch a red screen very briefly before proceeding to display the lock screen normally. I believe it is very similar to issue #341?
I have tried out niri 0.1.9 on arch extra and 0.10.1 on arch extra-testing, and they both showing same glitch.
Thank you for this amazing project!
System Information