Document list of supported protocols

[DemiMarie]

I was not able to (quickly) find a list of protocols Smithay supports.

[elinorbgr]

So, let me give you some background, because "supported protocol" can mean different things depending on what you need.

Supporting a protocol extension can require 3 levels of integration:

1. Code to handle the communication part of this extension: meaning deserializing the client requests to present them into a practical type, and serializing high-level events from the compositor into the protocol as defined by the extension.
2. Depending on the extension, some specific support from the backends may be needed to support them.
3. High-level logic to back the protocol general behavior and plumb the parts together.

Part 1 is what lives in smithays wayland module, which currently has support for the core protocol, xdg-shell, linux-dmabuf and explicit-synchronization (that last one being untested), but we plan to add support for several more general protocols.
Part 2 is only required for some protocols (for example linux-dmabuf, wp_viewporter).
Part 3 can be significantly tied to the individual logic of your compositor, and is at the moment not handled at all by Smithay. We plan to built more abstractions regarding that with time.

If I understood correctly your plans as you described in #297, you will be very interested in part 1, part 2 will be handled by your custom backend, and you will need some unique logic for part 3, as you're going to be involving the backends in some things that are generally not expected of a compositor (for example clipboard handling), and your relationship with the backends will be pretty specific (your compositor does not draw directly but instead forwards buffers if I understand correctly). The internal logic of your compositor would also be quite simple, as if I understand correctly there is basically one app per qube, so you don't really need to do any window-management.

So, the way Smithay is currently built, you could just use the part 1 and roll your own specific logic for parts 2 or 3. Our module are loosely-coupled so this kind of partial use is completely possible and within our scope.

I don't know how easy this would be done with wlroots, you'll need to ask them. My understanding is that wlroots is more integrated than Smithay, and provides a lot of abstractions for handling part 3.

[marmarek]

as if I understand correctly there is basically one app per qube, so you don't really need to do any window-management.

That's not fully accurate, there may be several apps per qube, but still the window management is responsibility of the actual compositor (in GUI qube) which the windows will be forwarded to.

[chrisduerr]

#781

[PolyMeilex]

I make sure that the list in #781 is up to date, therefore I'm closing this.