swaywm
layer-shell surfaces can display over swaylock
layer-shell surfaces can display over swaylock, allows interaction with applications despite the session being locked.
wldash, for example, will display over swaylock if left open when swaylock starts. This allows full access to a functioning launcher while the session is locked.
Lockscreens need some mechanism to guarantee that they're the only visible and focused surface on every output.
This is by design. Some people want to, for example, show notifications even if the screen is locked (though wldash is wrong to use the overlay layer). However, the input inhibit protocol should give swaylock exclusive access to input events, preventing these applications from being interacted with.
If the overlay layer is meant to show over lock screens, we need to have a warning somewhere, at least in the protocol text where I couldn't see any mention of special interpretations. I only discovered this by accident. I chose overlay based on the protocol documentation, picking what seemed the most logical for a HUD-style overlay surface.
It's less severe with working input inhibition, but wldash captures the keyboard when running over swaylock. It also captures if using a top layer under a full-screen surface (but only after a few key-presses for some reason).
(Also, side-note: I can't get wldash to show if swaylock is started first, so I imagine notifications won't show either as is.)
Some people want to, for example, show notifications even if the screen is locked
otoh, some people (including me) don't want to show notifications if the screen is locked. But if the layer is top instead of overlay, then it won't show above full-screen apps.
On the linked bemenu issue it was suggested that perhaps there should be another layer that is above full-screen apps, but below the lock screen, that would be suitable for things like launchers and notifications if the user doesn't want them to appear while locked.
This (and a few similar issues) can be closed: since https://github.com/swaywm/swaylock/commit/ac3b49b6571ceda3f8db11a98bfe320106996280, swaylock only uses ext-session-lock-v1, which does not have this issue.
