I think it's fascinating how general opinion seems to be becoming more neutral on Wayland compared to the rah-rah days I remember, probably around 2018-19. I personally could never use Wayland - I was pretty set in my i3 config, so GNOME switching to Wayland didn't affect me, but I always had PCs with nvidia GPUS (I like playing games, sue me) and while admittedly, nvidia wasn't working on good faith either, I don't think nvidia users deserved the attitude they got from eg. Sway. Despite that, the amount of effusive praise Wayland got on HN and some linux-centric communities had me jealous. What changed over time? I see that this gist was made in 2020, was it the issues with screensharing that became more pronounced due to COVID induced WFH? Did some major distro enable Wayland by default and therefore brought people out of the woodwork? If someone knows what the history is here I'd be delighted to know.

Of course, it's entirely possible I'm misreading the history here: Wayland could've been widely despised back then, or maybe this thread is an outlier. Either way, I'd be happy to see if anybody's got a good pulse check.

The problems don't change the fact that it's better & smarter & obvious, and honestly the problems here are... frequently misstated ("Wayland provides no capture APIs"... uhhhh what? this ticket is closed & resolved >2 years ago & webrtc for example works fine.). Leaving X to have a massive rats nest of drivers, and giving every app supreme access to the session, was a terrible situation, and Wayland is a reasonable, far lower surface-area alternative that's far more sensible & leaves far more responsibilities in the kernel's trusting hands.

This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread.

What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example.

Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem.

That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.

I guess what I never understood about Wayland is how they managed to ignore some very obvious problems X11 had, and created brand-new ones.

The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there.

The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15).

Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows.

A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.

All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.

Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.

Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.

Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.

Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)

> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.

I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.

> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.

We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).