I agree that X is the odd duck out in its attempt to follow the Unix philosophy. Wayland further pursues the “GNU is Not Unix” principle by introducing a modern desktop paradigm to pair with its modern application busses and other modern features.
Fair. The point I’m trying to convey - without burdening the reader with too many specifics - is that there isn’t really any problem with Wayland on non-Linux systems per se, but rather fundamental philosophical and design differences that spiral way out into other parts of the operating system and beyond (into hardware).
A question like whether or not IPC and application buses are managed by a supposed display manager is a more complicated decision than it appears on the surface, with lots of questions that need to be asked that feel like you’re challenging the literal meaning of words depending on which contextual paradigm you’re approaching the discussion from.
The net result is Wayland being a reasonable solution to a real problem that still further isolates Linux into a GUI desktop silo. The result is only “cross compatibility” if you consider the “cross” to mean across Linux distributions, which - in fairness - is actually what most people DO seem to mean.
> Windows & Mac are already on exclusively Wayland-style compositors
Only in a narrow sense; nearly all of the features one might reasonably consider fundamental parts of Windows/Mac are “out of scope” for Wayland. Wayland relies on layers upon layers of other solutions for things like central registries, interprocess communication, and negotiating hardware access.
From the Wayland perspective, this is all perfectly reasonable. It’s just how software gets made.
From the perspective of someone who isn’t already running a Linux kernel with evdev + KMS + DRM, we aren’t able to even find common language to discuss what being “a compositor” means to Wayland.
OpenBSD uses and actively supports a customized (not forked) X called Xenocara, which takes the opposite philosophical route from Wayland by putting a wider part of the ecosystem of X features into one coherent project so it can be maintained, improved, and culled (simultaneously, and without committees). You can learn about it on the Xenocara project pages and in its robust manual pages.
If you read other comments in separate parts of the threads here, you’ll see people describing re-scoping certain elements “out” of Wayland and “into” other layers to fix “broken” parts of X. Those “widely agreed upon” solutions for other layers exclude considerations for the way OpenBSD works in fairly fundamental ways that make it seem (to me, at least) there is no practical purpose in exploring Wayland on OpenBSD beyond the point it has already been explored.
I’m speaking about the coherent and supported OpenBSD operating system, not what can be found in packages.
If there ever become features fundamental to the current user-developers of OpenBSD that are enabled by Wayland, I would expect them to further modify Xenocara to support those use cases, but it is hard to even imagine what those could be. Most of Wayland’s promised future features are anti-features to the OpenBSD approach.
I expect that in 5-10 years, many user applications will be Linux-only, and there will be many conversations about how stubborn BSD (and Windows/Mac) designers are for not aligning to earlier decisions made on their behalf.
These are just my personal opinions with no inside knowledge from any part of this intellectual territory, and I do not accuse or blame ANY developer on ANY project for working on what they are interested in, but I expect this unified Linux (and Linux-only) outcome is the unstated but express purpose behind promoting Wayland for some of the commercial interests that support it.
I want to doubly emphasize that I am talking about the motivations of executives determining the allocation of capital and human resources, not about the motivations of the developers, which are clearly to facilitate cool or useful new things.