[kaba0]

> None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases

The wayland protocol is multi-layered, with the core being deliberately only used for displaying content in recrangles properly. That’s it. But it also allows for querying the capabilities of the compositor with versioning, making extensions possible. There was a recent Show HN submission with this site: https://wayland.app/protocols/

The not-yet-core extensions doesn’t create fragmentation, actually there is a decent cooperation behind the 3-4 major compositor “backends” on everything, and ultimately they all settle on the same thing. Also, it’s a bit generous to say that fragmentation is somehow the fault of Wayland, when it has always been a problem in linux desktops.

Also, why do you think adding screen recording into wayland would have been great? It is a complex problem with audio syncing, not-necessarily display-related programs accessing streams and the like, so it seems relevant only on a surface level. Pipewire is the good layer to handle it. And prebaking some API without pipewire being ready would have been just stupid. It is/will be supported everywhere (there is a portal frontend already for gnome, sway and I believe plasma as well).