Since Wayland is still quite new to a lot of people, it’s often difficult to figure out which features the Wayland compositor you’re using actually supports. While the Wayland Explorer is a great way to browse through the various protocols and their status in various compositors, there’s now an easier way. The Wayland protocols table makes it very easy to see what your favourite compositor supports, which compositors support the protocol you really want supported before leaving X11 behind, and much more.
Roughly speaking, there’s a set of stable core Wayland protocols, as well as a slew of unstable core Wayland protocols that are still in development, but may already be supported by various compositors. On top of that, compositors themselves also have a ton of protocols they themselves introduced and support, but which aren’t supported by anything else – yet, as they may be picked up by other compositors and eventually become part of Wayland’s core protocols.
Keeping tabs on specific protocols and their support status is mostly only interesting for developers and people with very specific needs, since mature compositors provide a complete set of features most users never have to worry about. Still, that doesn’t mean there aren’t really cool features cooking, nor does it mean that one specific accessibility-related protocol isn’t incredibly important to keep track of. These websites provide an easy way to do so.
I don’t know what else could have been expected from the Wayland standardization process except complete fragmentation of the Linux desktop.
Yeah. It won’t take long for contradictions and irreconcilable issues arises that will make compositors incompatible with each other and with client software targeting protocols outside the glacial moving core. Gracious fallback mechanisms will get eventually too complex.
As much I think that X11 had to go, Wayland was the wrong choice. It’s adoption was knee jerk reaction against Canonical and their Mir library (who where far more architecturally coherent than this whole “protocol” mumbo jumbo of Wayland) at the apex of the fight between Red Hat against Canonical (where Canonical played all its cards wrong, and now, all core Linux workstation infra is controlled by Red Hat).
We are at the sunk cost issue here: projects invested so much resources on Wayland, that now going back and trying something else isn’t an option. So, like lemmings heading towards a cliff, everybody is just walking forward hoping that everything will just work out at the end.
CapEnt,
Yeah, the two things can be simultaneously true. X11 had an aging clunky code base, but Wayland was being pushed through without fully addressing user’s needs, which has now translated into wayland feature fragmentation.
Haha. Fragmentation can happen naturally, but it seems obvious to me that they miscalculated the needs of users from the very beginning and this has has had a negative impact on the project’s direction and rollout.
There will come a point where wayland will get “profiles”, as XMPP did with its Compliance Suites. https://xmpp.org/about/compliance-suites/
There is no other way when going with an extensible protocol.
The@Serafean
There are two possibilities I guess. Apps could apply “feature detection” techniques like web apps do.
Or there can be “profiles” that specificy mandatory support for otherwise “optioional” extensions like with RISC-V. The XMPP suites are similar but more complicated.
I kind of like the RISC-V model, though both approaches can be combined of course.
XMPP is “both” as in every XEP (feature) has a detection mechanism, and the Compliance Suites are more like a checklist for developers what they need to support to actually be useful. Protocol negotiation is here to stay.
We don’t want to repeat what happened with OpenGL: instead of looking for needed extensions, developers just looked for the version. So if an extension that was part of a version profile wasn’t implemented, even if the program didn’t use it, the program failed to start because the specific GL version couldn’t be claimed as supported.
Really super basic things – like drawing consistent and uniform window controls – are still boycotted by Gnome: https://wayland.app/protocols/xdg-decoration-unstable-v1
Every X11 window manager can do it. Windows and macOS can do it. KDE, COSMIC, Budgie, LXQt, Hyprland and other Wayland desktops can do it. But not GNOME.
No wonder people think Wayland is still “broken”.
@Unopposed0108
Yes, when Cage and Louvre support it and you don’t, it is pretty sad.
I think the isolationist attitude is hurting GNOME. They have lost a lot of market share to KDE in recent months. If COSMIC gains market share, I expect it to come mostly at the cost of GNOME.
It may get harder to throw their weight around when they have 12% market share instead of being the de-facto Linux desktop. That said, they do get an awful lot of soft-power from being part of the Red Hat Linux platform (which is kind of the new UNIX/POSIX).
LeFantome,
I agree. Wayland & gnome have gone down a path that amplifies isolation and feature fragmentation. However I am not as sure it came at the cost of GNOME. From where I sit it seems that other desktops have been on the loosing end of this friction.
Yeah, other ponies are in the race but redhat usually determines the winners.