fix(sessionlock): wait for first frame by screenlocker client - #1215
Open
Lubsch wants to merge 1 commit into
Open
fix(sessionlock): wait for first frame by screenlocker client#1215Lubsch wants to merge 1 commit into
Lubsch wants to merge 1 commit into
Conversation
Lubsch
force-pushed
the
session-lock-wait
branch
from
July 24, 2026 00:25
482b722 to
cb1c1d9
Compare
Context: The Session lock protocol (https://wayland.app/protocols/ext-session-lock-v1#ext_session_lock_v1) requires us to ensure that we display frames by the screenlocker on all outputs before sending "locked", which we do by blanking all monitors to be gray (`locked_bg`). This can be circumvented with the `allow_lock_transparent` option but it's off by default. I've set up my screenlocker to run before suspend. I've noticed a problem using mango: The gray blank frame is shown on wake up because it was the last one to be drawn before sleeping. Then, on my machine, it persists for a few hundred milliseconds (normal wakup freeze) before reaching the screenlocker. This looked pretty jarring to me, going from black to gray to my screenlocker. Following "every frame is correct", I think this should be improved. This change makes mango wait for the first frame by the screenlocker and only then send "locked". If `allow_lock_transparent` is on, it keeps the old behavior (locking immediately). This change diverges from the spec: > The compositor may wait for the client to create and render session lock > surfaces before sending the locked event to avoid displaying > intermediate blank frames. However, it must impose a reasonable time > limit if waiting and send the locked event as soon as the hard > requirements described above can be met if the time limit expires. > Clients should immediately create lock surfaces for all outputs on > creation of this object to make this possible. We don't have a timer as the spec would require. But a screenlocker not sending frames after requesting a lock is very unlikely and because we render blank frames (`locked_bg`), it's not a security concern. We could add a timer later but I decided against that code weight for now.
Lubsch
force-pushed
the
session-lock-wait
branch
from
July 24, 2026 00:28
cb1c1d9 to
0169e0b
Compare
DreamMaoMao
force-pushed
the
main
branch
3 times, most recently
from
August 10, 2026 05:15
0efe75b to
20ad711
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
The Session lock protocol1 requires us to ensure that we display frames by the screenlocker on all outputs before sending "locked", which we do by blanking all monitors to be gray (
locked_bg). This can be circumvented with theallow_lock_transparentoption but it's off by default (see #448)Issue / Fix
I've set up my screenlocker to run before suspend. I've noticed a problem using mango: The gray blank frame is shown on wake up because it was the last one to be drawn before sleeping. Then, on my machine, it persists for a few hundred milliseconds (normal wakup freeze) before reaching the screenlocker. This looked pretty jarring to me, going from black to gray to my screenlocker. Following "every frame is correct", I think this should be improved. This change makes mango wait for the first frame by the screenlocker and only then send "locked". If
allow_lock_transparentis on, it keeps the old behavior (locking immediately).This change diverges from the spec1:
We don't have a timer as the spec would require. But a screenlocker not sending frames after requesting a lock is very unlikely and because we render blank frames (
locked_bg), it's not a security concern. We could add a timer later but I decided against that code weight for now.Footnotes
https://wayland.app/protocols/ext-session-lock-v1#ext_session_lock_v1 ↩ ↩2