Ideas on adding wlr-layer-shell

[ehopperdietzel]

Hello @Paraworker and @Fox2Code, I'm implementing wlr-layer-shell and I would like to know your opinions before proceeding.

Currently, Louvre provides a list of surfaces (LCompositor::surfaces()) that respects the Z-order of surfaces according to their roles (from bottom to top) and offers the method LSurface::raise() to modify that order. However, if, for example, raise is called on a surface with the role of subsurface, its topmost parent and the entire subtree of surfaces are elevated, not just the subsurface. This is done to maintain the Z order of the protocol.

Each surface also has LSurface::prevSurface() and LSurface::nextSurface() to access neighboring surfaces in the LCompositor::surfaces() list, and a virtual method LSurface::orderChanged() that is invoked whenever the surface's position in the list changes. This allows, for example, maintaining and updating the order in an external list such as when using LScene and LView.

However, wlr-layer-shell introduces the concept of layers, specifically:

1. background
2. bottom
3. top
4. overlay

The protocol mentions that generally surfaces with other roles should be placed between the bottom and top layers, and fullscreen surfaces should be in the top layer.

Therefore, what I'm planning is, in addition to having only the LCompositor::surfaces() list, to also add the following lists:

1. background
2. bottom
3. middle
4. top
5. overlay

• Surfaces without a role would be in the middle layer.
• Surfaces with the wlr-layer-shell role could be in any layer except the middle one.
• Surfaces with the cursor or dnd icon role would be in the overlay layer.
• Session lock surfaces would be in the middle layer.
• Toplevel surfaces would be in the middle layer and in the top layer if they go into fullscreen mode.
• Other roles such as subsurface or popup would be in the same layer as their parent surface, including top-level modals.

If the user calls the raise method, the surface(s) would be raised within their current layer. I don't want to add an API to reassign a surface's layer, that would allow the user to break the protocols order, if the user desires that, they can maintain their own lists.

Each layer would maintain its own internal order, which would also be consistent with LCompositor::surfaces() (containing all surfaces).

If the user disables the wlr-layer-shell protocol, everything would remain the same, but there simply wouldn't be any surfaces with that role.

Each surface would have a method to access its current layer and a virtual method that would notify when it changes layers.

The idea of implementing everything this way is to maintain the current API (which in my opinion is simple for the user, although not so much for Louvre internals), but before implementing it, I would like to have your feedback.

Regards

[Paraworker]

I don't want to add an API to reassign a surface's layer

The layer of wlr_layer_surface can be changed, a layerChanged() callback may be required?

[ehopperdietzel]

as long as compositors are allowed to break standards

😉

The only main request I have is just for the compositor to be able to conditionally ignore the client request.

Yeah, that can be accomplished by only exposing the protocol to well-known clients.

I haven't had time to work on Louvre lately, so there's been no progress. I'm deciding between wlr-layer-shell and ext-layer-shell. Since most clients use wlr-layer-shell, I might stick with that for now.

[Fox2Code]

I would like to see a way for Louvre to interpret 2 different protocols as one, for cases where Louvre needs to support 2 protocols that do the same thing.

The ext-layer-shell seems to be a draft here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28

So I'll say for now, only supporting wlr-layer-shell is the way to go.

[ehopperdietzel]

Hmm yeah, I think the day ext-layer-shell is officially released, I'll probably keep wlr-layer-shell for a while before removing it. Same with wlr-screencopy.

[Fox2Code]

Well, just remember software will keep using old protocol for a while (A few years), I honestly think Louvre should have a way to support multiple protocols that do the same thing at one at the code level.

For example supporting both wlr-layer-shell and ext-layer-shell in https://github.com/CuarzoSoftware/Louvre/tree/2.0.0/src/lib/protocols/LayerShell

Due to Wayland infighting, some protocols may take years to decades to be merged and widely used, so Louvre really need some sort of system to properly handle that.

[ehopperdietzel]

Yes, I think I can easily add support for both and provide a single API.

[ehopperdietzel]

@Fox2Code wlr-layer-shell is now working! Here’s a demo: https://www.youtube.com/watch?v=lS9wvJtjbYw

I won’t add more protocols for now. I'll focus on polishing the API, performing tests, and updating the tutorial and documentation. Once that’s done, v2.0.0 will be ready for release :D

[ehopperdietzel]

proprietary NVIDIA drivers added explicit sync in 555, but the default on arch is still 550, so maybe it's best to wait a bit before focusing on Nvidia too much, implementing the explicit sync protocol can be nice though.

I agree, but there is still a lot of room for improvement, especially related to multi-GPU setups and buffer allocation. Unfortunately, there is almost no documentation available, so I think I'll send an email to the Mesa guys one of these days, asking for some guidance on specific things.

You don't have to follow the following versioning rules if you don't want to.

I know, but I try to. That forces me to overthink the API design, hopefully making it simple and flexible at the same time.

I said before as long as XWayland is not a thing, I think Louvre should be considered work in progress and you should take your time for everything important.

I will implement it at some point. Luckily, most apps nowadays run natively on Wayland (except for games, I believe). At least all the ones I use do, so I don't think XWayland is such a big deal. But maybe I am wrong?

What I'll say is take your time, Louvre is a big project and not easy to manage.

Exaaactly, step by step...

[Fox2Code]

I will implement it at some point. Luckily, most apps nowadays run natively on Wayland (except for games, I believe). At least all the ones I use do, so I don't think XWayland is such a big deal. But maybe I am wrong?

Progress on the Wayland driver seems to be stalled on Wine for now https://gitlab.winehq.org/wine/wine/-/merge_requests/4947

Also Java doesn't support Wayland for now, and Wayland patches for java are work in progress. (See java project Wakefield)
As for me java GUI support isn't something I cannot get away not having, XWayland is a must and not a may have.

My X11 setup work fine for now, but I'll still keep supporting Louvre because of what it could be.

[ehopperdietzel]

Well, then it seems worth adding. It will probably take me some time to implement it properly since I'm not familiar with it, but in the meantime, it's on the TODO list.

[Fox2Code]

A wayland compositor is more complex to make than an X11 windows manager, according to XWayland documentation, the compositor need to also be an X11 Window manager to support XWayland.

The only question I have, is how will X11 virtual window coordinates will be implemented in Louvre API

[ehopperdietzel]

The only question I have, is how will X11 virtual window coordinates will be implemented in Louvre API

Good question. From what I know, there is a root window, and all others are positioned relative to it. In Louvre, there is the concept of global compositor space, which is used to arrange both displays and surfaces. Therefore, I think I could just place the root window at (0,0), or let the user assign it, but I guess it would be more complex than that.