Question: How does Smithay handle (additional) Wayland protocols?

[orowith2os]

I can't find any documentation on how Smithay handles the protocols, and I'd like to know, since Wayland has some fragmentation due to each compositor needing to implement its own protocols for some features.

Are users of Smithay intended to implement the protocols they require, such as wlroots protocols?

If it were to implement its own set, I made a similar issue at pop-os/cosmic-protocols#8 that suggests to work with wlroots to use their protocols and decrease fragmentation of the Linux desktop, and got a response saying, quote:

"... As you can see there is active work going on for all protocols to reduce fragmentation long-term. We will continue making protocols, where functionality is lacking for features we want to provide. And I cannot promise you, that we won't end up with one or two private protocols for certain shell functionality, but we are actively trying to use established solutions and participate in developing new ones.

Additionally we are already using wlr-protocols, where they already seem a good fit. E.g. the wlr-layer-shell and the wlr-output-configuration protocol, which are both fully supported by cosmic-comp."

[orowith2os]

Additionally, there was an attempt at wlroots Rust bindings, but they are now unmaintained and suggest to use Smithay for an alternative Wayland compositor library: https://github.com/swaywm/wlroots-rs

[Drakulix]

Wlroots bindings are not required (nor particularly helpful in the context of smithay) to implement protocols.

Smithay currently provides a bunch of implementations for different protocols, though mostly for common protocols found upstream in wayland-protocols (with some exceptions like wlr-layer-shell).
We don't try to cover everything, but a lot of the stuff commonly found in all compositors to keep maintenance of all implementations manageable.

Users of smithay are neither forced to use any of the provided implementations nor to rely on smithay exclusively for those implementations.
Meaning downstream (like cosmic-comp) can implement whichever protocols they wish to use.

[WhyNotHugo]

To clarify further: Smithay isn't re-inventing protocols, it's implementing support for existing protocols (which are the ones implemented by wlroots or others).

Just because it's a different codebase doesn't mean different protocols are used; these are all fetched from existing sources. You probably want to look at https://github.com/Smithay/wayland-rs/ which is used under the hood here.

[orowith2os]

To clarify further: Smithay isn't re-inventing protocols, it's implementing support for existing protocols (which are the ones implemented by wlroots or others).

Just because it's a different codebase doesn't mean different protocols are used; these are all fetched from existing sources. You probably want to look at https://github.com/Smithay/wayland-rs/ which is used under the hood here.

This is good to know. Where would I go to document this? I want to be sure it's taken note of for the future.

[Drakulix]

This is good to know. Where would I go to document this? I want to be sure it's taken note of for the future.

We wanted to have a list of supported protocols and their version for quite some time.
I guess we could just stick that right in the README, if you want to make a PR for that.
If you need any help compiling the list, feel free to write here or chat with us on matrix (or bridged to IRC on libera.chat).

[i509VCB]

This is good to know. Where would I go to document this? I want to be sure it's taken note of for the future.

We wanted to have a list of supported protocols and their version for quite some time. I guess we could just stick that right in the README, if you want to make a PR for that. If you need any help compiling the list, feel free to write here or chat with us on matrix (or bridged to IRC on libera.chat).

This would be nice, I'd have a separate readme for that table though

[orowith2os]

If a list of the supported protocols gets added, it seems appropriate to put it in the docs.rs rather than a README, imo

sneak edit: or maybe both