Now that Wayland is the default display manager on Zorin OS 17 Core and Zorin OS 17 Pro, it becomes more critical that users understand Wayland and the implications of Wayland.
Wayland is often described as "new" and "modern." In actuality, however, Wayland was initially released in September of 2008.
It has taken a great deal of time to get to where we are today, with Wayland actually generally working on many systems. Wayland... is not new.
One of the primary rules of Linux and a tenet of FOSS is that we do not break user space.
This is a very simple rule. It is basic and easy to follow.
And the trouble with Wayland is that it breaks this rule.
Let's look first at the pros and cons. What makes Wayland appealing? What makes it unappealing?
Wayland merges display server and compositor as a single function. In X-windowing, this is a separate feature, along with the Window Manager as a client side process. While Wayland simplifies this, it also reduces the feature availability of both window management and compositing. So even as the process is simplified, so, too are the results.
In Wayland, the compositor receives pixel data directly from clients whereas in X-windowing, the compositor must fetch all pixel data. This produces latency in X-windowing, but not in Wayland. However, this is measured in milliseconds, far below the threshold for human sensitivity. You cannot notice, see or experience this speed difference which invalidates the argument that Wayland is faster.
Wayland delegates that rendering is performed client-side. X-Windowing can either permit rendering from the client or perform rendering with its compositor. With Wayland, some rendering can appear smoother but X-windowing can perform multiple instances of rendering and allow more features and functionality while Wayland remains hard-coded to be limited in features and functionality.
Wayland does not support sessions, selections and drag and drop. This must be handled solely by the Desktop Environment. X-windowing can handle all the familiar features. This is because the X Server communicates directly with the client-side and the kernel. Wayland allows the kernel to communicate directly to the client. This has been one of the strongest arguments in favor of Wayland. Indeed, it was the argument that initially gained my support for Wayland. It simplifies the process and cuts out the middle man. However, in practice, it is shown that this is an oversimplification. Wayland is handicapped by being unable to handle the basic features of a Display and the inability for a go-between in communication limits what a desktop environment can provide the End User.
Wayland isolates the I/O of window to API communications, delegating communication exist only between an active application and the display at a time. This, too, has been an argument in favor of Wayland by saying it provides better security than X-windowing. However, to make this argument is misleading. For one thing, X-windowing was patched many years ago to limit access to the display from applications, a factor proponents for Wayland seem to "forget" to mention and instead suggest that the X server does not do so (Yet, the X server does do so). Further, an API must communicate with display in order to produce a GUI application. Only with Wayland, it does not need to also work its way through the in-built securities of X-Windowing to get there. Since the display must be accessed, whether all at once or one at a time, the end result is exactly the same.
The above gives us some insight into the pros and cons of Wayland and X-windowing. From the above alone, we could easily conclude that this must be a user choice; based on the needs and preferences of the user.
Well, it isn't. Remember, Wayland is intended to fully replace X-Windowing.
And here is where we meet the Trouble With Wayland: It breaks API's, which breaks the very first and primary rule of Linux. It breaks user space.
I will quote Linus Torvalds:
The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users.
So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make.
Without the users, any and every project is nothing. It is meaningless without the user base. This is because any project is supposed to be useful and helpful for those that use it.
On Zorin OS 17 using Wayland, it breaks Gnome-Screenshot. This is why Zorin OS 17 does not include the Gnome-Screenshot package, but instead has screenshot (With less features and functionality) built into the shell.
Using Wayland, Nvidia breaks. Zorin OS must default back to X windowing in order to unbreak itself.
Wayland does not respect EWMH protocols and breaks CLI tools like xprop, xrandr, wmctrl, preventing user controls and access of their display management and ability to adjust necessary features like Refresh rate and Resolution.
Wayland breaks all X11 applications. A stop gap measure was added in the form of XWayland, which is considered a temporary means of providing basic support for these applications on Wayland.
Wayland breaks screen-sharing and remote desktop applications.
Wayland breaks Window Management - which is why Wayland is not on XFCE or many other Desktop Environments.
Wayland breaks accessibility tools and assistive technologies which, let's be honest with ourselves, is probably the worst thing you could ever break and maintain a conscience.
Wayland breaks many features of Multi-Monitor support like display hotplugging, resolution management, display arrangement and other features.
Here's the problem: Whenever Wayland breaks something, they maintain shifting the blame onto - everyone else. They say that app developers need to get Wayland Compliant. They say that Distributions need to conform to them.
They say that the users must get onboard with Wayland. The onus shifts onto every non-Wayland party to do what Wayland says we are supposed to do for them.
Everything it breaks, we are told to find work-arounds for or to use Wayland now, as it breaks things, and wait for someone else to provide a fix.
This is the antithesis of what Linux is: Do Not Break User Space. If your API breaks user space, it must be reverted. No Regressions.
Wayland does not respect the User Base that provides the purpose of its existence. This is because Wayland is not for the users. It is for the developers.
It breaks the users workflow and performance, the users expectations of application features and functionality. While it has some pros, in the end, Wayland shifts blame for their breakage onto the users whom they gave no choice to nor accepted input from.
They tell us that we were supposed to just accept what they offer. Whether you believe Wayland is better or X is better falls to the side. It no longer matters. What matters is the users and Waylands disregard for the users is the growing Direction of developers. Just like Microsoft. Just like Google. All the things we came over to Linux to get away from. We came over to Linux because Linux has a rule: Do Not Break User Space.
That is the Trouble With Wayland.
The name is in all caps.)