I'll try to fill in some of the knowledge gaps and respond to some of your answers from a more user-centric perspective.
A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.
And users don't care. All they care about is "Under X11, my desktop would recover from KWin/Mutter/Openbox/whatever crashing. Now it kicks me back to the login prompt."
(This was achieved by having Xorg so ossified that no effectively stability regressions were creeping in, and by having the "when this quits, the session ends" anchor for the X session be some small, simple process that would restart the window manager if it crashed.)
Microsoft redesigned their driver model in the mid 2000s so that Windows could recover from video driver crashes without losing your whole session and people have been faulting Linux for being stuck in the past ever since. This is a step backward.
Since Wayland doesn't implement the kind of architecture Microsoft used to retrofit that onto existing Win32 apps, fixing the problem falls to the patches David Edmundson has been writing for various Wayland client implementations to implement compositor handoffs, which enables behaviour similar to Windows's GPU reset handling by having the session handler restart the compositor and then the applications reconnect and restore their state.
What, like allowing Windows to see your keystrokes, which makes developing a keylogger absolutely trivial?
There are legitimate complaints... usually relating to standard-steerers dragging their heels and/or playing responsibility hot potato on coming up with APIs related to accessibility and activity tracking that aren't proprietary APIs that only work on one compositor... if the compositor supports them at all.
Yes, because Wayland is a set of protocols, which a bunch of projects can implement as few or as many of, as they see fit, thus avoiding the issue of “unmaintainable mess” that has plagued Xorg for years.
There is an argument to be made about fragmentation though.
The answer is that:
-
Wayland's use of protocol extensions and vendor prefixes is similar to how OpenGL and Vulkan use them.
-
What we're seeing are teething problems and Wayland is currently in the state X11 was in back in the 80s and early 90s when there were dozens of implementations with wildly different sets of extensions on offer.
-
We're already seeing a trajectory that will probably eventually see everyone except maybe GNOME converging on having wlroots be the shared backend that takes the role Xorg used to serve.
It offloads work to the window manager: Again, yes, that’s a part of its structure: do the protocols, then let the compositor implement them. That way, you have multiple implementations running simultaneously that are well integrated with their window managers and thus more efficient and performant. It also means that when a compositor suffers from too much cruft, we can just make a new one, while application developers wouldn’t really have anything to change because if their application works on Wayland, then it works on different compositors (unless it is made specifically for GNOME, or specifically for wlroots, like wlr-randr)
Again, I don't think anyone would notice or care what the split is between the various components except that it's breaking people's workflows and desktop customizations. People were up in arms about Windows Vista because of the big bump in system requirements and the driver stability issues, not because of specific reasons why those happened.
…so what works on DE 1, doesn’t necessarily work on DE 2: True, because oftentimes, it doesn’t need to. Not implementing features can lead to a more lean and streamlined software solution. However, sometimes features are necessary and only implemented in some compositors. This usually happens because the universal solution is not ready. KDE are often known to do this with Plasma and KWin.
And probonopd replied to one of my comments by saying he feels that Wayland is the "KDE applied the 4.0 moniker to a developer release and Canonical ignored the 'not ready for end users' warnings" part all over again.
Yes, he's sensationalist and opinionated and abrasive and his points are masked by the staleness of the links, but there is a fair point to be made. As this video points out, as soon as you step outside major DEs like KDE or GNOME toward the "build your own experience from building blocks" things power users often gravitate toward, the readiness of Wayland's ecosystem falls off a cliff and turns into a game of "Identify which utilities are compatible with this wlroots-based compositor".
As stated IN YOUR FACE, it is an application that works on X11 only. Yes, Wayland is not made to use such applications, but it doesn’t mean they can’t exist. Every heard of ydotool (remember that name)? Now you have.
Commenters have pointed out that not all xdotool commands have ydotool equivalents.
xdotool is capable of things like sending events to a specific window, searching for windows by name or class, focusing/minimizing/maximizing/moving/closing/etc. windows, and hanging event handlers off windows using the behave subcommand, such as the "Print the window title and pid whenever an xterm gets focus" or "Emulate focus-follows-mouse" examples in the manpage.
ydotool is completely incapable of any of that because, to achieve what it does, it circumvents Wayland's security model entirely and uses the Linux-specific /dev/uinput kernel API (which is usually pref'd to only be available to root for good reason) to inject input events at a level where, if Wayland started being selective, they'd break userland drivers like the old g15daemon that was needed to get some of the keys on the Logitech G15 gaming keyboard to produce recognizable events.
By any metric, that's going in the exact opposite direction of what the Wayland security model was intended to achieve since, if a malicious process can invoke xdotool, the calls like XGrabKeyboard that are used to implement screen lockers and high-security password prompts will exclude it, similar to how Microsft's UAC prompts will shut out software KVMs like Synergy/Barrier but, if malicious code has access to ydotool without the user having done something like setting one sudo NOPASSWD rule for each command they use, with no variance allowed, it'll sail right through as easily as if they had one of those spy cables with a WiFi reverse shell payload and a USB HID endpoint physically plugged into your PC.
(And if access to /dev/uinput has been loosened instead of the user deciding to set a NOPASSWD rule on sudo ydotool and use that, then malicious code can set an exclusive grab on the evdev node for you keyboard, re-emit everything it sees (a combination intended for things like g15daemon which need to remap events to avoid getting duplicated keystrokes) and man-in-the-middle keylog all keyboard input.)
The article quotes that “Redshift does not support Wayland since it offers no way to adjust the color temperature” which is not true, as proven by Redshift alternatives like Gammastep.
...and the Gammastep README says:
Why doesn't this work with Wayland compositors like Mutter, KWin, Mir, and Enlightenment? This program supports the wlroots protocol for gamma adjustments, but several Wayland compositors do not support this protocol. GNOME and KDE have their own built-in mechanisms for adjusting color temperature on Wayland.
What the README doesn't say is that the KDE built-in mechanism has no facility for setting the daytime color temperature and I still run the GUI frontend to Redshift on my KDE+X11 machines because it has the F.lux-esque "disable for an hour" option KDE lacks as of Kubuntu 22.04 LTS. (For that, the only option is Win+N to toggle night mode off and then manually setting an alarm to remind me to manually toggle it back on.)
Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure, but Hyprland has not allowed that to stop them from implementing a solution where you can choose keys that will be passed on to the application. Boom, problem solved. Unfortunately, it doesn’t seem to be implemented anywhere else, as far as I know.
As others have pointed out, there's now an XDG portal for this which various desktops have implemented... I'm very happy about this because, as a developer who's resorted to XGrabKey to get DE-agnostic global hotkeys under X11, I should finally be able to integrate into KDE's global hotkey management KCM without having to write a special path for one desktop.
Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.
TL;DR: nVidia dragged their heels on implementing the de facto standard GBM GPU memory management API for a decade, then finally responded to KDE's "we won't write a backend for a single-vendor proprietary API" stance by writing the EGLStreams backend themselves and providing the KDE maintainers with a liason to the driver developer team... KDE promptly started sending them running to the team with questions about how to implement various features they already had working on GBM and that finally convinced nVidia that EGLStreams was not fit for this purpose.
See this chatlog for more details.
These days, it's more that nVidia's driver only does explicit sync all the way through and, while Wayland's "every frame is perfect" is partly about making the app→compositor part explicit-sync, there's still work being done to plumb that all the way down to the video driver, which means things like flickering can still occur on nVidia hardware last I checked.
(I haven't tried Wayland myself, because I spent years flat-out blocked from it by my KDE use and my GeForce GTX750 GPU and, as someone who leaves his systems logged in for months on end, I'm now waiting for the aforemoentioned compositor crash recovery patches to get all sorted out... though, since I recently received a hand-me-down Lenovo Ideapad from 2016 with Intel onboard graphics, I'll probably start experimenting with it once I have a moment.)
Wayland complicates server side decorations: From what I’ve heard, this is true, mainly something to do with some GNOME agenda, as the article states. I think that one is true.
As I understand it, it's that Mutter would require such a huge internal re-architecting to do it performantly that the GNOME developers just put their foot down, refused to implement the protocol extension to negotiate for SSDs, and doubled down on forcing games to implement their own windeco drawing if they wanted titlebars and borders when not fullscreened.
Thankfully for all the game ports we might otherwise not get, Icculus stepped up and implemented titlebar-drawing in SDL... though, last I saw a screenshot, the fallback from "request SSDs using the protocol KDE pioneered" to "draw our own CSDs" was still producing conspicuously ugly titlebars.
Wayland breaks RescueTime: Because RescueTime depends on X11-only tools like xprop.
No, because automatic time trackers like RescueTime require the ability to monitor what you're doing and the devs are of a "You don't get to use automatic time trackers because your granny might get confused by a 'This application wants to track what you're doing' permission prompt" mindset. See flatpak/xdg-desktop-portal#304 for details.
Quote from article: "As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. "
I'll quote Bjorn Stahl (the Arcan developer)'s closing statement from Arguementing Client-Side Decorations here:
It is to no surprise that GTK, EFL and others agree on the current situation, as they have already done the work, thus this empowers them at the cost of everyone else. Pundits also typically chime in and say something like “everyone is using a toolkit anyway” to which I say, step out of your filter bubble and widen your sample set, there are plenty of “raw” clients if you know where to look. The natural follow up from the same crowd is something to the effect of “you shouldn’t write a wayland client manually yourself, use a toolkit” – which is nothing but a terrible excuse and undermining the point of agreeing on a protocol when the details gets masked inside library code, it means moving the complexity around, making it less visible, rather than actually reducing complexity.
Adding a dependency to a million-line codebase is a really weird way of making something “simple”.
If the point of wayland is, in fact, the often claimed “make it simpler” and the suggested solution turns out demonstrable worse than the dominating one in that regard, a band aid suggestion of ‘hide the complexity in a library’ is farcical at best.
Real simplicity is observable and permeates all components in a solution, and the reality of Wayland is anything but simple.
The italic emphasis is present in the original.
Wayland break games: I’m 99% sure you can disable Vsync??? But I’m not a gamer. Also, WINE on Wayland is getting better and better. Soon enough, I hope the subpar performance will become better performance (when compared to Xorg)
It's a relatively young optional extension to the protocol. Wayland's "every frame is perfect" mantra embodies an overcorrection for X11 being fundamentally based on an immediate-mode drawing API.
The tearing-control_v1 extension was only added in Wayland Protocols 1.30 in in November 2022, and wlroots only merged support for it into the repo head (merged, not released) on September 28th, 2023.
Wayland breaks xkill: Well, yes. Again. It is an X application, so of course it does. Though for some reason I remember it working once on wayland. Must have been an xwayland app, or maybe I’m just misremembering this.
I think the complaint for this one is that, aside from one-line scripting hacks for specific wlroots-based compositors (not even wlroots overall), Wayland has no replacement for the "click a window to kill it" workflow.
Wayland breaks setting the window position: That is a WIP for Plasma, not sure about any other projects, so assume true for anything else.
There's active discussion on how to design a solution for letting multi-window applications save/restore sessions and lay out multi-window UIs that the compositors won't refuse to implement.
(The latter link is especially contentious, with part of the argument being convincing the potential implementers that it's even a legitimate design decision for an application to have secondary windows that didn't originate by the user tearing off a panel/toolbar and thus, would fall under session save/restore.)
Also, maybe things have changed but, last time I heard anything, Plasma's APIs for window positioning were only exposed to things registered as KWin scripts. (In essence, out-of-process compositor plugins.)
Wayland breaks window icons: Yeah, that seems to be the case, as said in the article, when no .desktop files are used.
Discussion is in progress around how to support portable applications and running things from git clone checkouts for development purposes.
I'll probably follow the LibrePCB devs' lead in locking my creations to XWayland || die semantics until the problem is resolved.
I already take a pass on KDE Plasma's in-taskbar progress notifications since they use a Unity-originated API with a similar dependence on having an installed .desktop file and I don't want to have to manage a .desktop file as part of iterating on a development version while maintaining a clean user profile.