wlroots 0.17 Adds New Wayland Protocols, Continued Vulkan Renderer Work

[phoronix]

Phoronix: wlroots 0.17 Adds New Wayland Protocols, Continued Vulkan Renderer Work

Released on Tuesday was a new version of wlroots, the Wayland compositor support library that was born out of the i3-inspired Sway compositor project. With this new release are new Wayland protocols, continued work on their Vulkan renderer, and the ability for the Wayland back-end to embed a wlroots compositor inside an existing Wayland client...

https://www.phoronix.com/news/wlroots-0.17

[keit99]

What's the use case for running a wayland compositor as a wayland Client?

[Pheoxy]

What's the use case for running a wayland compositor as a wayland Client?

Gamescope and things like it I guess.

[timofonic]

ehopperdietzel

How does it compare against Louvre? Any collaboration plans? Protocols and such, for example.

[jeisom]

Are there any compositors using wlroots that are implementing any kind of plugin window management system? Think X11 and window managers/DEs, just for wayland. I think a lot of the smaller de projects could use something like that. They'd just need to implement the window management side, panels, theming, etc. Only 1 allowed, same security as other wlroots, bugs not withstanding. Obviously wlroots is a big help for those smaller projects already. Kind of wish gnome and upstream kde used it as well.

[ehopperdietzel]

ehopperdietzel

How does it compare against Louvre? Any collaboration plans? Protocols and such, for example.

I find it fascinating that wlroots includes numerous protocols. Currently, Louvre only implements basic protocols, which can be limiting, but on the other hand (in my opinion), it provides a simpler experience. Essentially, Louvre can be seen as a straightforward and educational tool, enabling more people to learn about Wayland at a high level and experiment with creating their own compositor. Later on, if they desire more modularity, they would already have the basic knowledge to use wlroots. As for contributing, I don't consider myself someone who could be of assistance to wlroots; they are the experts, haha. They help me learn how to implement certain things by examining their code. I believe the best way I can contribute to wlroots is by implementing the protocols they themselves have created, possibly aiding in their faster consideration as standards.

That being said, I also want to clarify the misunderstanding regarding fragmentation. The fragmentation issue worsens only if someone decides to create their own protocols that only a few use, as is the case with some compositors in certain distributions. Nevertheless, I don't blame them either; they must be tired of the lack of generic solutions for certain problems. Therefore, they take a step forward, which, if proven useful, could be adopted by everyone.

What I do think would be fantastic is for Wayland experts, graphics and input driver developers, and toolkit developers to come together in one room to rethink how to approach each problem. They should reconsider what is useful among the existing solutions and what is not, reaching an agreement to make the entire stack (drivers, compositors, apps) consistent so that everyone is happy, and no one continues reinventing protocols to achieve the same goals.

[Steffo]

Are there any compositors using wlroots that are implementing any kind of plugin window management system? Think X11 and window managers/DEs, just for wayland. I think a lot of the smaller de projects could use something like that. They'd just need to implement the window management side, panels, theming, etc. Only 1 allowed, same security as other wlroots, bugs not withstanding. Obviously wlroots is a big help for those smaller projects already. Kind of wish gnome and upstream kde used it as well.

There is Sway, Hyperland and as far as I know also Mate and Cinnamon plan to adopt wlroots. I've also read that even KDE is thinking about using wlroots in the long term.
In my opinion, the last thing we need in the 21. century, is another C project which many projects depend on. I've looked into the code and it's the typical C-stuff: Reimplementing a linked list, reimplementing a for-each-loop, manually parsing like the Linux kernel version and so on. Really stupid, error-prone and security-relevant stuff are manually reimplemented and other projects are adopting it. Really, why are so many Linux/Unix-guys so backwards-oriented?
This project has been created while there was modern C++ and Rust.

[WorldlinessFlimsy672]

What's the use case for running a wayland compositor as a wayland Client?

Nesting your sway session in a sway window for example.

Eg you want 2 sway workspaces on one monitor, which gives you all the features of workspaces for each side of your split screen.

[ehopperdietzel]

I find it fascinating that wlroots includes numerous protocols. Currently, Louvre only implements basic protocols, which can be limiting, but on the other hand (in my opinion), it provides a simpler experience. Essentially, Louvre can be seen as a straightforward and educational tool, enabling more people to learn about Wayland at a high level and experiment with creating their own compositor. Later on, if they desire more modularity, they would already have the basic knowledge to use wlroots. As for contributing, I don't consider myself someone who could be of assistance to wlroots; they are the experts, haha. They help me learn how to implement certain things by examining their code. I believe the best way I can contribute to wlroots is by implementing the protocols they themselves have created, possibly aiding in their faster consideration as standards.

That being said, I also want to clarify the misunderstanding regarding fragmentation. The fragmentation issue worsens only if someone decides to create their own protocols that only a few use, as is the case with some compositors in certain distributions. Nevertheless, I don't blame them either; they must be tired of the lack of generic solutions for certain problems. Therefore, they take a step forward, which, if proven useful, could be adopted by everyone.

What I do think would be fantastic is for Wayland experts, graphics and input driver developers, and toolkit developers to come together in one room to rethink how to approach each problem. They should reconsider what is useful among the existing solutions and what is not, reaching an agreement to make the entire stack (drivers, compositors, apps) consistent so that everyone is happy, and no one continues reinventing protocols to achieve the same goals.

I also forgot to mention that I believe the initial choice of Wayland's design, being so modular and extensible, was an excellent idea. From what I understand, a significant portion of driver APIs was tightly linked to X11. As they became more generic, developers could experiment by creating different protocols to incorporate into Wayland. However, as far as I know, there is now an entire infrastructure in place to allow Wayland compositors to offer the same functionalities as X11, such as efficient screen recording and multi-GPU support. Therefore, I think that Wayland's extensibility is no longer as necessary, and there is a need to be more decisive and propose protocols that everyone must (and wants to) adhere to.

There is also the aspect of toolkits; seemingly simple things like preventing apps from knowing their position on screens and making it complex or impossible for them to position themselves have broken many functionalities. This supposedly gives more control to the compositor and enhances security, but it seems that nobody desires that. So, as mentioned earlier, I believe reaching a consensus involving all stakeholders is essential.

[timofonic]

There is Sway, Hyperland and as far as I know also Mate and Cinnamon plan to adopt wlroots. I've also read that even KDE is thinking about using wlroots in the long term.
In my opinion, the last thing we need in the 21. century, is another C project which many projects depend on. I've looked into the code and it's the typical C-stuff: Reimplementing a linked list, reimplementing a for-each-loop, manually parsing like the Linux kernel version and so on. Really stupid, error-prone and security-relevant stuff are manually reimplemented and other projects are adopting it. Really, why are so many Linux/Unix-guys so backwards-oriented?
This project has been created while there was modern C++ and Rust.

ngraham

Any plans for KDE trabsitioning to wlroots, Louvre or similar? Any efforts by KDE to share code between other FOSS projects? Budgie is interested on this, along Xfce LXQt etc.

romangg
What do you think too?