[joshklein]

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.

[kllrnohj]

> 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.

Windows & Mac are already on exclusively Wayland-style compositors, they made that transition years & years ago (Vista was Microsoft's transition, for example, which was 13 years ago now). Why would they have any issues here?

[joshklein]

> 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.

[kllrnohj]

All of the features that are considered "out of scope" for Wayland are also out of scope for other OS's compositors, too. So not in a narrow sense at all.

Wayland is one thing, not an X replacement. There is, unfortunately, not a great story/push to standardize all the other parts of X outside of Wayland's scope.

But it's important to recognize those other parts are also very much not handled by the Wayland-equivalent on other OS's, either. Window's DWM doesn't do clipboard management. Android's SurfaceFlinger doesn't do input. MacOS's QuartZ Composer doesn't do global keyboard shortcuts. And from an app perspective, none of those other OS's conflate those random unrelated things in the way X did, either. They aren't part of the same library or technology group. As in, you'll never find clipboard references in CoreGraphics. You use NSPasteboard which talks to the pastboard server, instead. Entirely unrelated & orthogonal to the compositor, as it should be.

Only on Linux is a full desktop environment stack shoehorned into what's supposedly a display manager.

[joshklein]

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.

[kllrnohj]

I got your point, but I'm flat out disagreeing with it. Wayland aligns Linux with the philosophical & design differences of other OS's, it doesn't diverge at all.

In the same way that X's unique snowflake design hasn't significantly impacted cross-OS compatibility, why would Wayland make this any harder? If anything Wayland reduces cross-OS complexity as you can finally have a compositor API on Linux like you have on literally every other OS, which greatly reduces the friction for things like embedding video within an app.

But otherwise right now on any cross-OS application the design is going to assume that composition, clipboard, and keyboard shortcuts are all independent systems. Only on X is that not true. X is the unique, unorthodox design in the broader world of "all OSes"

[joshklein]

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.

[grandinj]

I so glad to see there are still people practicing sound engineering in this world.

The driving force behind Wayland appears to be commercial interests that have no interest in the desktop use-case per-se.

The linux-only outcome is purely an unintended side-effect.