split overlay layer and add all input device

[Ongy]

I split the overlay layer into an explicit locking layer and an
explicit input area layer.
This avoids ambiguous z-order for applications that should have a well
defined order.
I also added intended usecases to the documentation. Those are mainly
to set up for discussion.
It would be beneficial if everyone has a simliar model of how this
protocol should be used, so these should be informational.

I also added an "all" flag to input devices. This is intended for
session locking tools, to be able to lock all input, without having to
be updated for the mos current protocol spec with newer input devices.

[emersion]

ping @SirCmpwn

[ddevault]

locking isn't necessarily the only purpose of overlay

[ddevault]

I'm not sure about this but I'm leaning towards being on board with it

[ddevault]

I think you should find ways to describe each layer's purpose without resorting to specific examples. I can come up with many examples for software in each layer that doesn't match the examples you've given.

[emersion]

I agree. I'm still not sure how to solve z-index conflicts though. Maybe keep overlay and add a new layer?

[ddevault]

Let me stew on it for a bit.

[Ongy]

Thinking about this a bit more, what do you think about removing screenlockers from the suggested users of surface layers?

We can specify that they should be between top and overlay (or overlay and input/accessability) to make sure it's positioned correctly (in terms of z-order) with applications for surface-layers.

This would also solve an issue I currently have with exclusive input in surface layers.
Should they get priority over the compositor consuming events?
I for example would prefer screenlockers to be able to block tty-switching, but I wouldn't expect normal applications to be able to do that.

[ddevault]

Screen lockers should not be able to block tty switching. Still stewing on the approach.

[Ongy]

Screen lockers should not be able to block tty switching.

I disagree. That makes the difference between a session and a system locker.
And I would very much like to have system locking support. Lack of that has been one of my annoyances in the X environment.
I do see a security/permission situation here and would probably only allow it, if a root owned config file permits it.

But the point about compositor event consumption still stands.
The same general problem exists for workspace switching, or if someone implements something like "hot corners" where some action is triggered by moving the pointer into a specific area.
But this may not be locking specific, so it may make sense to just add a priority kind of thing in surface layers.

[ddevault]

Well, the protocol specifies such interactions to be compositor defined and I think wlroots would be flexible enough. You're welcome to make waymonad behave that way.

The same general problem exists for workspace switching, or if someone implements something like "hot corners" where some action is triggered by moving the pointer into a specific area.

What's the problem?

[Ongy]

Mainly that I'd have to guess whether an applicatoin is supposed to have priority over the compositor consuming events or not. But then again, I'm not sure there is an actual use case where an application would request exclusive input without expecting to block things.

[ddevault]

Here's how I want to resolve z-ordering:

• Keep the original layers defined as they were
• Add a namespace string which clients can use to categorize themselves, e.g. "tray" or "lock-screen"
• Let users configure z-ordering based on namespace, and add sensible defaults as we see what kinds of namespaces shake out in practice
• Always render popups at z = max(parent surface's layer + 1, shell surfaces layer + 1)