-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
session-lock: lock the screen even if the client provides no lock surface #2550
Open
dkondor
wants to merge
4
commits into
WayfireWM:master
Choose a base branch
from
dkondor:lock_no_surface
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
7b4f78d
session-lock: lock the screen even if the client provides no lock sur…
dkondor 1c5d5d4
session-lock: define crashed urface in one location
dkondor a79d191
session-lock: ensure that the crashed surface is displayed even if th…
dkondor 4dc41b8
session-lock: address review
dkondor File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we hide the crashed node once the actual lock node is there? I think for example if one wanted to implement a blurred lockscreen, or animate the lockscreen surface, this would prevent it from working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potentially, however, after doing some tests with the current implementation, I'm a bit confused how this should happen:
This is especially strange given that both projects seem to use the wlr-screencopy protocol to get a screenshot of the current desktop contents. Do you happen to know of another lockscreen app that does not make a screenshot, but just simply displays a (partially) transparent surface? That would allow me to test this more cleanly.
On a second thought, actually it could even make sense to not show the desktop after the previous lockscreen has already crashed. Contrary to when originally locking the screen, it could be a security / privacy issue if the screen contents are revealed when restarting a crashed lockscreen (however briefly). But then it is very weird why the screen shows up with shaderlock, I'll investigate that separately a bit more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a guess, maybe they take the screenshot at different times?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that can be.
Now I realized what we have here does not actually matter, since a new instance is created when a new lock client connects:
wayfire/plugins/protocols/session-lock.cpp
Line 460 in 4dc41b8
So that would also explain why the desktop becomes visible even with shaderlock (I assume it takes the screenshot before creating the new lock then). Maybe it would make sense to refactor this so that the crashed node is kept until the new client creates a lock surface and thus the screen cannot be revealed accidentally. However, that would be a bigger change and IMO unrelated to the current PR -- I can create a separate issue and try writing a patch for it if you think this can be an issue. Note that I've only seen this with shaderlock, probably because it is a bit slow to display its initial lock surface (e.g. swaylock appears fast enough). In any case, this is likely not a common issue, since most lockscreens do not crash, and even in that case, the problem manifests only if there is some automated way to restart them which could trigger when an "unauthorized" user is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I've just tried gtklock and it is also slow enough that the unlocked desktop flashes, but in this case really briefly (barely possible to notice it).