Consider using wlroots for Cinnamon/Muffin's wayland session

[ryanabx]

Originally, I saw this suggested in this issue: linuxmint/wayland#25

I want this space to serve as a discussion for the future of Cinnamon on wayland. I believe that there is ample time to discuss the future of Cinnamon on wayland and users shouldn't try to rush the developers of cinnamon.

wlroots gitlab: https://gitlab.freedesktop.org/wlroots/wlroots

Note: I'm going to preface this by saying that I am not at all an expert on compositors, I have never developed for a compositor; however, I would consider developing for one if I found the direction it is going exciting enough, but I can't claim to have experience for it. I also don't want this topic to imply that work should be done in a certain way. I feel it's really important in free software to honor the direction a project is going because it's the developers that define the project's direction, not an end-user or some other external force.

Why wlroots?

Other desktop environments that do not have the developer manpower to support a full compositor from scratch are using wlroots to build their wayland session support.
See:
XFCE: https://wiki.xfce.org/releng/wayland_roadmap
Budgie: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1423165-budgie-ditches-mutter-for-wlroots-and-teams-up-with-xfce-for-wayland-future (sorry for referencing a forum post, not the best source but it's the immediate one I could find for budgie)
LXQT (potentially? it says support for "sway", which utilizes wlroots): https://www.reddit.com/r/linux/comments/x10h1w/lxqt_developers_announces_support_for_sway_and/ , https://github.com/selairi/lxqt-sway

Pros

A summary of what I believe to be the pros of using wlroots over mutter:

• Moving to wlroots allows more flexibility moving forward, the compositor can be written how the LM team wants instead of working around potential rebasing from the upstream mutter
  • The LM team for instance can implement protocols not supported by mutter but are supported by wlroots
  • Muffin can benefit from the upstream development from members of XFCE, Budgie, LXQT, and Sway's development teams, and also contribute to wlroots when needed.
• A change moving away from mutter could potentially attract developers from other projects to help contribute to wayland support in cinnamon.

Cons

• The main obvious drawback to using wlroots instead of mutter for the wayland session is that muffin is heavily based on mutter, and changing dependency to wlroots would require a ton of developer manpower and time to rewrite a majority of the compositor code for the wayland session.
  • I do believe however that it would be time well spent, because it saves more potential heartache in the future.
• The cinnamon applets are GTK-based, not necessarily a compositor problem but the connection to GTK, and GNOME will remain even if wlroots is used. Correction: the cinnamon applets are clutter based, thanks @lestcape

[Conan-Kudo]

Pros

A summary of what I believe to be the pros of using wlroots over mutter:

• Moving to wlroots allows more flexibility moving forward, the compositor can be written how the LM team wants instead of working around potential rebasing from the upstream mutter

  • The LM team for instance can implement protocols not supported by mutter but are supported by wlroots
  • Muffin can benefit from the upstream development from members of XFCE, Budgie, LXQT, and Sway's development teams, and also contribute to wlroots when needed.

• A change moving away from mutter could potentially attract developers from other projects to help contribute to wayland support in cinnamon.

I think it's important to note that you don't actually get everything for free when building on wlroots. The wlroots project's origins as the backend library for Sway influences a lot of its design decisions. And while it's true you get a head start implementing a compositor on wlroots, it would not be terribly different than if you did so on libweston (from Weston), Louvre, or Mir either.

There is also another component that has to be implemented alongside a compositor: an xdg-desktop-portal backend. While wlroots has an implementation in the form of xdg-desktop-portal-wlr, it is so limited in functionality that compositors that use the library that want things to work have to implement their own backend. This is why Hyprland has its own, for example. I know that @JoshStrobl, @serebit, and I have discussed this before in the context of Budgie desktop that one will be made for Budgie once Magpie v1 is further along.

Any alternative needs to also consider that Cinnamon needs a portal backend that is linked to the compositor too in order to be fully useful as a Wayland environment.

Cons

• The main obvious drawback to using wlroots instead of mutter for the wayland session is that muffin is heavily based on mutter, and changing dependency to wlroots would require a ton of developer manpower and time to rewrite a majority of the compositor code for the wayland session.

  • I do believe however that it would be time well spent, because it saves more potential heartache in the future.

• The cinnamon applets are GTK-based, not necessarily a compositor problem but the connection to GTK, and GNOME will remain even if wlroots is used. Correction: the cinnamon applets are clutter based, thanks @lestcape

Clutter is part of Mutter/Muffin. It hasn't been a separate project in a very long time. Eliminating Mutter/Muffin essentially forces a total rewrite of the whole shell, since the Cinnamon shell, like the GNOME shell, is implemented around Muffin.

It also eliminates the opportunity to reuse the GNOME desktop portal (or at least to fork/extend it). As prior art, elementary OS' Pantheon desktop uses Mutter directly and is able to largely reuse the existing infrastructure, only needing to build a portal implementation for its own piece to set backgrounds.

@jadahl has already confirmed it's technically possible to implement more protocols in Mutter as needed. It's more of a question of whether anyone wants to do it. To be clear, there are absolutely limitations in Mutter due to what they've been willing to implement so far.

Fundamentally, Cinnamon is a fork of GNOME Shell. It inherits GNOME Shell's architecture. Changing to anything else means throwing away the shell code completely and starting over. Maybe that's fine and Cinnamon wants to do that, but that's a tremendous amount of effort that may not be worth it.

[Conan-Kudo]

I think it's important to note that you don't actually get everything for free when building on wlroots. The wlroots project's origins as the backend library for Sway influences a lot of its design decisions. And while it's true you get a head start implementing a compositor on wlroots, it would not be terribly different than if you did so on libweston (from Weston), Louvre, or Mir either.

Interesting, my assumption was that the wlroots team aimed to have all protocols implemented, and let the compositor devs pick and choose which protocols to include. Of course there's more work to a compositor than protocols, and would definitely take more time than forking mutter's wayland compositor, but I figured that most design decisions on the library side would have little impact on the compositor itself.

No. They will accept contributions for any protocol in the xdg- and ext- namespaces, I think, but they do not guarantee that they themselves will implement them all. That's also true for Mir and Weston, I believe. I would also hope that's true for Mutter, but that's a question to ask the Mutter folks. @emersion (wlroots), @AlanGriffiths (Mir), @fooishbar (Weston), and @jadahl (Mutter) can confirm whether this is the approach their respective compositor projects take.

There is also another component that has to be implemented alongside a compositor: an xdg-desktop-portal backend. While wlroots has an implementation in the form of xdg-desktop-portal-wlr, it is so limited in functionality that compositors that use the library that want things to work have to implement their own backend.

Out of curiosity, why isn't there a more complete portals library for wlroots? It seems like if there's a library to help abstract the wayland implementation, there would be an official accompanying portals library.

Because just like Wayland protocols, there are portal protocols too. They need to be implemented in both the compositor and the portal backend software. The approach xdg-desktop-portal-wlr takes is that it translates the portal protocol to the appropriate wlr/ext Wayland protocol. However, outside of full-screen screencasting and screenshotting, there are no Wayland protocols to correspond to portal protocols, so wlroots' requirements to support more portals cannot be fulfilled.

You could, of course, build a higher level wrapper library around wlroots (or mir, or libweston, or louvre, etc.) that turns on the wayland protocols and implements the portal protocols so that desktops can quickly get a compositor built that supports the portal system. But it doesn't exist today, and until it does, every desktop needs to do it themselves.

[emersion]

The wlroots project's origins as the backend library for Sway influences a lot of its design decisions.

That isn't true. We've made a lot of effort to not design wlroots after Sway. This is a primary goal of wlroots: not being tied nor enforcing any particular compositor policy. wlroots has been used in many settings very different from Sway, such as a VR compositor.

it is so limited in functionality that compositors that use the library that want things to work have to implement their own backend

Hyprland is the exception here rather than the rule. The fact that xdpw is missing functionality is because someone has to step up and write the code. Hyprland have decided to do their own protocols instead of working on standard protocols that work for all wlroots compositors.

Interesting, my assumption was that the wlroots team aimed to have all protocols implemented, and let the compositor devs pick and choose which protocols to include.

In general yes, but if we strongly disagree with a protocol in particular, we might reject it from wlroots.

That said, nothing stops a wlroots compositor from implementing the protocol outside of wlroots, of course.

You could, of course, build a higher level wrapper library around wlroots (or mir, or libweston, or louvre, etc.) that turns on the wayland protocols and implements the portal protocols so that desktops can quickly get a compositor built that supports the portal system. But it doesn't exist today, and until it does, every desktop needs to do it themselves.

That is effectively what xdpw is… It's just missing per-window screen sharing at the moment.

[ryanabx]

That is effectively what xdpw is… It's just missing per-window screen sharing at the moment.

Does xdpw implement xdg portals that aren't related to compositors as well? Or just the ones that have an equivalent wayland protocol?

I wonder if one day we will see a project that combines projects like wlroots, xdpw (if it does implement all xdg desktop portals) and anything else required to have a wayland-portals stack on a desktop environment, as a mega-library :)

[emersion]

Does xdpw implement xdg portals that aren't related to compositors as well? Or just the ones that have an equivalent wayland protocol?

No, xdpw only implements portals related to Wayland compositors. So, for example, screen sharing is in scope but open/save dialogs aren't. The reason is that each DE may have its own preferred opinionated way to implement some of the portals (e.g. Mint would maybe want GTK open/save dialogs, and a Qt-based compositor would want Qt open/save dialogs).

[fooishbar]

They will accept contributions for any protocol in the xdg- and ext- namespaces, I think, but they do not guarantee that they themselves will implement them all. That's also true for Mir and Weston, I believe. I would also hope that's true for Mutter, but that's a question to ask the Mutter folks. @emersion (wlroots), @AlanGriffiths (Mir), @fooishbar (Weston), and @jadahl (Mutter) can confirm whether this is the approach their respective compositor projects take.

We're (as Weston) extremely unlikely to ever implement server-side decorations, but I don't know of any others that we're actively avoiding. Any of the rest which are unimplemented is just because we haven't had the use for them yet.

[AlanGriffiths]

No. They will accept contributions for any protocol in the xdg- and ext- namespaces, I think, but they do not guarantee that they themselves will implement them all. That's also true for Mir and Weston, I believe. I would also hope that's true for Mutter, but that's a question to ask the Mutter folks. @emersion (wlroots), @AlanGriffiths (Mir), @fooishbar (Weston), and @jadahl (Mutter) can confirm whether this is the approach their respective compositor projects take.

Speaking for Mir, I can confirm we don't guarantee we will implement all the "stable" protocols, nor all the "unstable" ones. And, while this is hypothetical, we wouldn't accept a PR implementing a protocol we strongly disagree with even if it got approved.

Out of curiosity, why isn't there a more complete portals library for wlroots? It seems like if there's a library to help abstract the wayland implementation, there would be an official accompanying portals library.

Portals is, like Wayland, a collection of protocols. Some of these overlap with compositor functionality, but most don't.

Really, what is needed for portals is someone defining hooks for compositor integration, that multiple compositors could work with, and a portals project that is compositor agnostic.

[lestcape]

Look, that would be great, but I think it would also be an utopia. It would be almost like asking KDE and GNOME to make a single DE with the two. What I mean is that in reality this library would end up being very abstract and the only thing it would really work for, would be to define a common API for everyone. Of course, this would be great for those who put the standardization of the entire Linux ecosystem above, but unfortunately it would be frowned upon by other people who put usually their project interests first, rather than the interests of the entire Linux ecosystem (for example: GNOME).

[AlanGriffiths]

I'm interested to know what the people mentioned think:

I think there is scope for sharing parts of the stack between desktop environments. Historically, that's what happened when the DE ecosystem (mostly) adopted Xorg. And there are common parts in the Wayland world: libinput, libwayland-server, libwayland-client, libwayland-egl, etc.

Obviously, there are choices: having a completely bespoke stack that one controls offers more options and "unique selling points" than having a shared stack. The question is always: does my project benefit more from sharing or being distinct?

Where a project controls both the DE and application toolkit, there's a lot of scope for being distinct. For smaller projects there's the potential for sharing those things that are not unique to the project. That does raise questions of governance and design but these can be solved.

Both wlroots and Mir have attempted to offer a DE agnostic approach to implementing a Wayland compositor with some success. I don't think either project currently has the resources to take on everything that portals covers (as noted above, very little maps to what compositors deal with).

I would be happy to support an independent portals implementation that can work alongside Mir based compositors. (I can't speak for the Lomiri devs at UBports, but I believe they would also be interested.)

[fredldotme]

Speaking on behalf of the Lomiri devs where we use Mir and are also considering some future with portals in mind,
I can say that switching an integral piece as the compositor is not without compromise in time, man power and workload, and should be carefully considered.

With that being said, for us Mir gives us a good common baseline for compositor-related tasks, while we are still trying to figure out a way forward with portals.
So while others might have some partially applicable solutions to portals, I'd personally welcome something that is shareable between projects as much as possible, even if somewhat abstract because when you take away all the conctreteness of each individual project the only thing left is the abstract. No one likes being left in the dust because of bad "business" decisions.

The way I see it currently could indeed result in something that is satisfying the needs of any shell developer (whether the shell is developed with Clutter, GTK, QML, whetever) as long as the willpower to share the work and integrate is there. Yes it would require some sitting together and mapping out what the needs of each individual project are, but politics and personal preference shouldn't stand in the way of providing a common playground to move faster, together.

I personally would like to get something off the ground regarding this for sure. The more helping hands the better and I'm sure we can get something rolling that accommodates for both the needs of Lomiri as well as Cinnamon and other projects, especially since we're all pretty much at the same level with regards to progress on this particular front.

[Conan-Kudo]

I think it would also be nice to have an implementation that could theoretically be shared with Weston too, though I don't know what the Weston people feel about the portals infrastructure.

[fooishbar]

We don't have any objections to portals. We haven't implemented them since Weston typically gets used in more 'closed' environments - usually it gets shipped in a product with a pretty fixed configuration/UI/etc, rather than in the super-open desktop kind of usecases. But we'd definitely be open to an implementation.