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

[ArenM]

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]

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]

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?