Skip to content
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

RFC: add ability for clients to be shown over the lock screen #8461

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ArenM
Copy link

@ArenM ArenM commented Nov 17, 2024

WARNING: this implementation proof-of-concept quality, I expect there are bugs. I
haven't done a cleanup pass to find them yet.

My goal with opening this pr now is to find out if the architecture is agreeable, so I can determine if I want to commit more time to this project.

This can be tested with this wvkbd fork. When wvkbd is running and the screen is locked, wvkbd should stay visible. And if wvkbd is run after locking the screen, swyalock should resize to make space for wvkbd and wvkbd
should be shown.

Motivation

The only way to use a lock screen on devices with no keyboard currently is if the lock screen implements an on-screen-keyboard. I'm not aware of any that do this.

The idea of adding this protocol is to allow applications (such as an on-screen-keybaord) to request they be shown over the lock screen so they could be used unmodified with swaylock.

Secondarily, on mobile phones it may be desirable to make and receive phone calls without unlocking the device (with user configuration). Being able to keep this logic out of the lock screen would be nice. This is a major factor blocking sxmo from getting a lock screen by default.

Known Issues / TODO

  • Is a protocol like this an acceptable way to implement this? If not I'd like to throw this away before putting more work in.
  • Develop a robust way to control what is shown on the lock screen. I think this could be done by attaching a "allowed over lock" variable to each node in the scene tree, which defaults to false, and hide any node that doesn't have it set when entering the lock state.
    • This is wrong currently, the application I'm using to test has a popup layer which doesn't opt-in, but is being displayed anyway.
  • Write a new protocol for this. kde's protocol is good enough for a prototype, but this is not a compatible implementation.
  • Move protocol glue code from sway/lockscreen-overlay.c into wlroots. I'm not sure how much should move yet, I need to study the structure of sway/wlroots more.
  • Should this be a privileged protocol? I need to do some more reading on this.
  • Ensure the layout is computed at the right time. Layer shell surfaces resizing now require the lock screen to resize too. I think I've done this, but I'm not confident.

@Nefsen402
Copy link
Member

I'm gonna say that adding this new bool to the existing layer shell implementation is a nope from me. Ideally, we could create a new layer for the lockscreen in wlr_layer_shell (and clarify the position of the other layers while we're at it) but we aren't accepting any more patches to wlr_* protocols. A new wayland protocol probably under the ext namespace would be the way to go there.

If we want to move forward with the KDE protocol, I would re-implement the protocol using bits and pieces from layer_shell and maybe a few helpers that are shared between the two.

@ArenM
Copy link
Author

ArenM commented Nov 17, 2024

If I'm understand you correctly, that would mean making a new ext-ession-lock-overlay protocol which would include most of wlr-layer-shell with just one layer and added events for lock state? That's a bit more complex than I was hoping, I'm going to need to spend some more time to convince myself whether that's necessary or over complicated.

I think you're right about having a separate layer, it's a bit more complex to implement initially, but should mean significantly less code is involved in drawing the lock screen. And clients that want to be displayed both when locked and unlocked would need to acknowledge state changes, which is probably a good thing.

we aren't accepting any more patches to wlr_* protocols

Why is that, are they being deprecated or just feature-complete? If they're being deprecated would it make sense to shelve this and come back to it when that's made more progress so it can tie into them?

@navi-desu
Copy link
Contributor

Why is that, are they being deprecated or just feature-complete?

deprecated, getting protocols "upstream" in wayland-protocols is prefered, as more compositors and clients can easily make use of them.

If I'm understand you correctly, that would mean making a new ext-ession-lock-overlay protocol which would include most of wlr-layer-shell with just one layer and added events for lock state?

the idea would to have ext-layer-shell instead of wlr-layer-shell, then add the "lockscreen" layer to the ext one, if i got it right

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants