I’ll start off with this: many of the links are misquoted, some don’t even support the points made with them, and some are highlighted supposed "broken" functionality with either wrong dates or bugs that have already been fixed.

Yes, Wayland is different than Xorg. It was a complete re-imagining of how a modern and less monolithic display protocol should look. Of course, breakage isn’t necessarily a good thing…​but at the same time, some form of breakage is going to be inevitable. As we’ll see soon, the breakage has mostly been confined to a few specific places (screen capture most notably), where the current X way simply would not work with a more secure protocol.

Now, I would be lying if I said this hasn’t taken a long time to develop, or that I haven’t missed some of these features, but Linux apps and development are done by many individual developers, whether volunteers or paid. As a result, a lot of work does take a long time to complete. That being said, X’s current policy towards things like screen capture and key binding is simply insecure, and it is inevitable that we will have to move away from it eventually.

Furthermore, is it really worth throwing the entire protocol away for screen casting (which works but needs more adoption) and…​global menus? I’ve been using Wayland on my primary system for ages, and the flag workarounds for screen capture in Chromium (as mentioned below) have been working fine for me. It’s not a perfect solution, but the benefits Wayland provides have far exceeded the amount of time I’ve had to spend tweaking the few things that weren’t working out of the box.

Some of Xorg’s core issues that required breakage to be solved in Wayland, such as it being trivially easy to create keyloggers or view any window without permissions really are things that you’d expect to see /r/linuxmasterrace mocking Windows over, not problems that we should ignore on a supposedly secure system.

One more thing I’d like to add: many of these links honestly make no sense as sources or were talking about entirely different things, with some discussion cherry-picked without context. Without further ado…​

Screen recording has been available in Wayland for quite some time now, via {link-pipewire} and {link-xdg-desktop-portal}. Now, the gist does make allusions to this:

This is…​really, just completely wrong.

I have no idea why anything here would require clients to use GLib. All of the portal APIs work over D-Bus, and Pipewire doesn’t even require GLib.

xdg-desktop-portal is not a Red Hat, GNOME-specific, or even Flatpak-specific project; KDE has a portal backend, and there’s even a backend for wlroots-based compositors. The portals even have support for snapd.

Even just looking at the top contributors, we see contributions from employees of Collabora, Igalia, and Mozilla, not just Red Hat.

Pipewire also is not really a project that’s particularly tied to Red Hat; yes, the main developer is from Red Hat, but he’s also a multimedia expert and one of the two creators of GStreamer (a project founded while the developer was still at Collabora). As of right now, Collabora is a leading contributor to Pipewire as well. Even the creator of JACK is interested in Pipewire, despite initially being skeptical.

A lot of the particular linked examples are just bizarre extrapolations:

This was targeting Linux screencasting in general as highlighted by the ffmpeg reference.

Looks like I missed the part where the Wayland developers had the ability to update every single project in existence and add full Wayland support. Better yet, the issue would indicate more lack of time by the developer to be able to push updates, not that Wayland "breaks everything".

Okay, this one is just laughable. An OBS developer also stated in the same thread:

which would imply that we can’t really stay with X screencasting either, thus ruining the entire "just stick with X argument".

Better yet, there’s already an RFC open for Wayland support. All the portals they mentioned as "incomplete" do already support the screencast APIs anyway, so their knowledge at the time about it was likely already outdated.

Now onto "screen sharing", which is the same API problem as "screen casting", but let’s entertain the idea that it’s actually two separate points:

First off…​this is two issues from the same repo. How does this count as two separate breakages? I don’t even know where "2016" comes from, because the second issue was created this year.

The quoted text was not in response to Wayland missing functionality; Pipewire already existed at this point. Rather it was related to browsers implementing the screencast API. This has been implemented in Chromium behind a flag for years at least, and it was only behind a flag because parts of Chromium’s UI flow assumed there was no permissions model, so it would ask the user to select a window to share after they already selected it in the Wayland compositor. This is actively being worked on in both Chromium itself.

Firefox has had it in Fedora via downstream patches for quite some time as well, and it’s also being actively worked on.

"Yes, let’s highlight a Linux client that is notoriously buggy and generally terrible."

Again, I don’t know why this is split into three sections. But first off:

The issue had nothing to do with this, and this is a gross misquoting. The issue reads:

In other words, this issue was showing something unrelated, and at the time, Wayland support was already working. The date used in the gist ("broken since 24 Aug 2018") is also incorrect, since it’s pointing to the date the linked issue was filed, at which point Wayland support was again working.

GTK’s own lack of support for global menus over Wayland itself had little to do with Wayland and more to do with GTK itself not wanting to support global menus, as the current global menu implementation was very closely targeting Xorg.

Next up:

In other words…​if you actually read the article, they were able to make it work on Wayland without the re-engineering. In fact, the whole point of the article was to highlight that they were able to get it to work.

The linked bug literally says this was fixed in 5.20.

This is literally the same link as above. Why is this a separate point?

In addition, non-KDE Qt apps already often needed tweaks to expose global menus, because it was always a separate plugin and not part of Qt itself, as shown by these hacks to make global menus work in RStudio.

Once again, this has been fixed:

Really, I’d argue the actual problem is trying to bundle every individual dependency into a single file and expecting the users to never have to add anything else? This is pretty bizarre especially because it’s no different than having to include the global menu platform plugin to make global menus work, which AppImages already need! In other words, this is just an AppImage problem and its style clashing with the Qt reliance on various forms of dynamically-loaded plugins.

The opening to the article says:

I’d like to make a quick jab at this statement: just because you don’t have issues doesn’t imply that aren’t issues that others are stuck dealing with or fixing. Xorg’s APIs are quite nasty, and developers have to deal with them. There are things that Wayland can support easily but X cannot, and there are people who have to deal with those.

This article covers a few of the reasons X is a mess:

Wayland has seen significant adoption in the embedded space:

It’s even used in TVs:

Of course, as mentioned in the intro, there are very real security benefits as well. I think it would be rather misguided then to only show it as a source of breakage and problems, rather than something that caused breakage in order to improve what could not be improved with the same APIs.