The Trouble with Wayland

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.


And the main reason that I use Zorin Desktop on Xorg ...... I can create enough problems by myself with out buggy software adding to it ....

You would think that having been around since 2008 that the developers would have fixed these problems but they are waiting for other software developers to cowdown to them and adapt their software to run on Wayland ....

If I understand you correctly ....


First, I am not comfortable with Wayland and generally agree with your opinion. However, I think it has a philosophical problem.

I support the rule itself, but I do not support it being an absolute. Because absolute rules take away our freedom. I believe that freedom in FOSS is not limited to copyright. These are my belief, though I do not intend to force them on others.

If you get the community to accept your views by the authority of Rules of Linux or Linus Torvalds, not the result of our thoughts, it will not benefit the community. If we accept it, we will stop thinking, and if we don't think, there will be no discussion, and if there is no discussion, the forum will lose its significance.


This forum has rules (Guidelines) and while no rule is ever truly absolute, this does not mean that any rule is also applicable to be discarded simply because you can claim "freedom." Freedom is also never absolute.

Having a solid foundation of ethical tenets is a good thing. You want to do the least amount of harm to the effect of the most benefit.

1 Like

So it is a choice of two imperfect softwares X or Wayland. There does not seem to be a candidate for a "neither of the above" vote.
Having to switch between the two on an application by application basis is unacceptable for most users, so they have to discover for themselves the least worst candidate for their workflow. That is not a good advert for GNU/linux desktop.


I am not taking issue with any rules or foundation, only with the way you are arguing. The superior ideas and persons of the past are easily deified and bind us. I know you are not silly enough to do that, but a third party who sees what you say may do it.

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

I am not a fan of making Wayland the default user experience as I have had my fair share of random things not working (IE if I don't have my games set to fullscreen (maybe i want them fullscreen borderless windows) the screen may flicker irregularly) but I can't agree with this statement.

Regardless of opinions, if something is faster (and measurably so), then regardless of if someone may notice that millisecond increase or not does not mean that the argument is invalidated. In fact, I would actually argue it's the observable benefits that a user will notice more so. For example, window tearing is essentially gone now when dragging a window across the desktop, and scrolling on a webpage is a smoother experience overall. This is definitely a benefit that Wayland brings to the desktop experience.

While I also have no proof of this (I'm going to actually do some experimenting tonight after work), while my FPS in games hasn't gone up or down, the feeling I get while playing is that of the frame times are more consistent. Again, this could be me taking the Wayland placebo, so I'm going to look into this tonight with hopefully numbers to either confirm or deny my gut instincts.

I also agree with @Hackgets in regards to the breaking of the user space. I agree that it is absolutely something that should not be broken. However, to say that it can never happen is weird, considering that any app that has some sort of update can break that in an instant, without any ill-intent meant by the developer or anyone else. Sometimes things just break.

Do I think Wayland should be default? No, it has a lot of issues. But I'd like to think the reason everyone is making this seemingly sudden (although not really given Wayland isn't technically new at this point) push to use Wayland is to force everyone to actually look into it and how things work. I know there's some developers out there that have refused since it was released to even look at it.


I firmly believe that if we do not radically rethink the way certain things work we cannot reasonably improve the Linux Desktop. This will come with breakage in early adoption, but ultimately it has advantages (that you have outlined)

I understand the sentiment behind "Don't Break User Space", but you're disregarding where it comes from, that being kernel development. Not only was X obviously never apart of the Linux Kernel, but also does that statement refer to developing the kernel in a way that doesn't break projects that depend on it. The statement does not mean "we shouldn't create another project that is different and can offer an alternative API to achieve similar goals to [XYZ]". By that logic, FreeBSD shouldn't exist because it can be used as an alternative to any GNU/Linux operating system with it's BSD kernel. Yes they're both Unix-Like, does that mean they need to share 1:1 ABI and API compatibility?

What Wayland is doing is not breaking projects that depend on X. It is being framed as breaking another project, but no, you can still run Xorg implementing X11, and run all your X Applications.

Framing Wayland as breaking X is fundamentally mis-framing the issue as Wayland being some sort of evildoer update to the X Windowing System when it is a seperate project that developers have decided to adopt over X. They could've also picked Mir while that was still around, would we then blame Mir for breaking X?

Hopefully not, as Mir was also a separate project from X.

or, to give another example of a different component, does Musl Libc break Glibc? No.
When an application is designed around Glibc, and it doesn't work with Musl Libc, that is not Musl Libc "breaking" the application, that is the application being designed around Glibc.

Similarly, Wayland doesn't break X because some application is designed around X.

I also want to offer insight into my thoughts on Wayland using a thought experiment:
Imagine for a moment, Wayland was developed without the Xwayland project. Imagine for a moment that X compatibility was never preserved in this way at all, but developers still adopted Wayland over time. Would we still blame Wayland for breaking X?

The chance that'd happen is probably much lower due to the fact that nobody tried to keep X compatibility around. The biggest reason that Wayland is getting so much blame in my eyes, and why so many people are saying it "breaks" X is because some developers tried to keep compatibility intact to the best of their ability by working on XWayland, so that there wouldn't be even more issues on the path to a Wayland transition with some programs simply not starting at all.

Another reason I can think of is that Wayland is advertising itself as a replacement to the X Windowing System, and many people take that as "oh so it has 1:1 API compatibility with X" when that is untrue. It was never meant as a drop-in replacement. XWayland is provided on a best-effort basis.

Ultimately, I don't believe Wayland should be getting the blame because developers have chosen it over maintaining

Yes, it would've been more convenient and would've preserved more features during the transition phase if XWayland never existed and we would all use X until Wayland is 1000% ready, but that is not how development works, and blaming Wayland for not keeping 1:1 compatibility with X11 is a take that I simply do not understand, and that I will probably never understand because it fundementally collides with how I logically dissect this entire situation. Not to mention that with less eyes on actually using a Wayland desktop, it would take thousands of hours more time to develop desktops based on it as there is much less eyes on reporting bugs and issues with various desktops running in such a setup.

the project was started in 2008, a 1.0 release was on the 22nd of October 2012.

X allows sandbox escapes because it doesn't have full GUI sandboxing. It is not just about inputs (which can be globally read from the X-Server) but also about protocol security. To achieve proper seperation between windows and a higher level of GUI Sandboxing you'd need to use a Multi-Server setup.

If you've ever ran a game with and without VSync for latency reasons, you know that you may not be able to pinpoint what is wrong as a human, but you can DEFINITELY feel it, that small difference in latency.

No, that is an upstream GNOME change that is also on GNOME on Xorg.

xprop and xrandr were explicitly written for X, as the name implies. wmctrl continues to work on any compositor that has supported it before and done a Wayland transition, like KWin:
Video for Reference

And also, EWMH were always meant for the window manager to implement [1], not X exclusively. Yes it's an X Standard, no that doesn't mean you cannot implement it on Wayland.

Pipewire. Yes that isn't "wayland native" by your definition, but it works better, across Wayland and X11, and gives users the feature. Do we need any more than that?

XFCE: Wayland Roadmap

That is a compositors' job, the display protocol is for clients to display stuff. That doesn't mean Wayland Compositors don't still implement this
(I won't send a recording of me hotplugging my TV.)

Reminder that the X Windowing System existed before Linux and was ported to Linux as a fun side project. both X and Wayland are also on FreeBSD for what it's worth.

  1. it literally has "WM" in the name ↩︎


Have you not, yourself, pointed out that Wayland is intended to fully replace X and that XWayland is seen as a temporary measure?
Your statement implies that we have control and an alternative, so nothing to worry about. Except that it contradicts that Wayland is to fully replace X, removing that alternative and user choice.

Noting what Wayland breaks is factual, not framing. To follow the logic:
The End User is what matters since that is what the projects are intended for: The performance, workflow and use by the user.
If a project disrupts, breaks or inhibits the workflow, productivity or even the API's or applications the user relies on, this is breakage of user space.

You are injecting an argument into my point (evildoer), yet what I said above stands by its own merit. Breaking user space disrupts the workflow and reliability of what the users relay on to process projects, work, games, entertainment, data management...
My argument is not that Wayland devs have long handlebar mustaches that they twirl with an evil grin.
Rather, that they have fallen back to placing the blame elsewhere and making excuses to rationalize and justify that what they are doing is necessary.

And... you are doing the exact same thing. You are saying that this is necessary and that we must do this for Progress and that we should manage our frustrations with it until Wayland Improves.
Wayland lacks many of the functions and features that X offers and that the user are attuned to and rely on.
Wayland takes those away.
Ok? So... what happens next? Why should we believe that Wayland will re-introduce those functions and features at some unknown future date? Why should we believe that it can, when it is incapable of doing so, now? Fifteen Years Later?
And so far, Wayland developments makes no statements nor promises to do so. Instead, the suggestion is that "we will get used to Wayland."

Um... Yes. Definitely. 100% they would. Are you kidding?
The entire GnuLinux community would have been up in arms is what would have happened!
All of the sudden the entire Display protocol changed and the users workflow was radically altered?

They would have issued a very loud report. Without any doubt.

This argument relies on the notion that Wayland actually does sandbox - it doesn't. This term is used because it sounds like something familiar and is similar in some ways to Application Sandboxing which containerizes the app to isolate it from Root.
However - In Wayland, this sandbox does not isolate the application from Root because it is necessary for the application to directly access the Display Protocol. For this reason, Wayland delegates it to one application having acess to portions it needs in that moment, whereas (initially, though this is no longer the case) the X -windowing system allowed the application full access to the entirety of the display protocol all at once.
This is why the security arguments made on the web are so misleading.
The end result is the same.

You are lifting the blame off of Wayland to place it on Gnome as I point out in my O.P.
However, it was necessary for Gnome to to do this in order to make the screenshot tool compatible with Wayland. Exactly as I described in the O.P.

No. Wayland breaks Gnome Screenshot tool. So, Gnome had to integrate it into the Gnome Shell in order to conform it to Wayland.

Your further arguments about EWMH, Xprop, etc perform the same as I describe in my O.P.
Shifting blame away from Wayland for the breakage. Yes, they are designed to work with a Window Management that Wayland lacks. By introducing Wayland, it is breaking what works and what the user relies on.
If you write a program that is not compatible with the existing frameworks, then you cannot say that it does not break them because you wrote it to not be compatible with them.
Rather, it is more accurate to say that it breaks them due to the lack of compatibility.

Yes, the XFCE developers have gone with CSD's and are considering transition. They openly state that they are not sure when or even IF they will implement a transition. It is based on whether they can figure out a way of doing it.
The very link you posted clarifies this and notes its dependency on window management and the necessity of maintaining it:

  • Keep X11 compatibility for the foreseeable future

    • Nvidia support to Wayland is still problematic, one more reason to keep X11 backward compatibility (nouveau driver usually is slower)

    • Wayland compositors which were written from scratch like Weston or sway will never run as a x11 window manager. But others which started as x11 window managers such as kwin or mutter still keep their x11 window management code

    • FreeBSD has decent support for Wayland, OpenBSD is still working on supporting Wayland

Wayland is the compositor.

I think my post here also addresses @Hackgets concern and your concern about the kernel team. In pointing out clearly why user space is the primary consideration, it is clear that the argument is not deifying either a person or a rule. It is exemplifying the importance of why all these projects exist: To Provide the End User with a usable and reliable Desktop Experience.

To violate this is to violate the very users all projects depend on for support.

Without the users; all projects are utterly meaningless. And we are wise to remember this.

1 Like

But never as a drop-in replacement.
Yes, Wayland is supposed to replace X as the display protocol, as that is what developers have been focusing on doing in the past couple of years as we move away from X. This does not however mean that Wayland was designed as a drop-in replacement. That would be more akin to something like Pipewire-Pulse, which is a drop-in replacement for Pulseaudio, just to give an example.

I don't think there would've been a way to keep 1:1 compatibility with X whilst also following Wayland design goals.

I was trying to go off of various things I've seen online, e.g the "Wayland breaks everything" post. The "evildoer" thing is not intended to come from your point. Sorry if that was not clear enough from my wording.

counter-question, did the X Windowing System have all of these extensions within the first 15 years? Barely. Infact, the RandR extension was not finished 14 years after X, as the historic paper going over RandR 0.91 mentions that, at the time of writing, the X Extension Framework had "served them well for the past 14 years".

Going off of the "last changed" date at the bottom, this was roughly in 2002, roughly 14 years after the X Windowing System was first envisioned

After some more digging, RandR 1.0 was apparently finished in 2002, on the 4th of October. You can see this when checking this commit and which lines it has removed.

This is an extension to X, with the equivalent on Wayland being literally the wlrandr extension. That was talked about in 2013 by Phoronix.

Some of the most common things that are complained about often have been fixed by the Wayland Contributors 11 years ago from now.[1]

Two things:

  1. GNOME Shell has had it's own Screen Casting interface, it only uses XSHM and XComposite directly as a fallback. This is evidenced by things like:
  2. Again, PipeWire.

Recording a traditional X11 desktop is easy with existing tools. Because every application can grab the window content of any window or monitor on the X11 server, screen sharing is rather simple to do. Many applications support this method like ffmpeg with the x11grab source or apps built with the Electron framework. The typical APIs for this are XShm and XComposite, which are only available on X11.

With wayland, this becomes more difficult from a developers point of view. The security architecture of wayland forbids unauthorized access to other windows. No capture API is provided by wayland itself.

Instead, applications must explicitly request the user to grant them access to a screen or window. This is done through xdg-desktop-portal, a D-Bus API that was originally invented for sandboxed Flatpak apps.

The actual window content is delivered through PipeWire in the form of a video stream. To access it, an application has to connect to this stream and negotiate a format with the stream source.

- Dafabhoid on Github

Before you say it, yes I know that says "No capture API is provided by wayland itself.", but does that matter to the end user if they can just select "Window Capture (Pipewire)" in OBS and call it a day?

How can something that did not exist to begin with break?
Do Windows Programs break on Linux because they aren't written to work on Linux?
What about macOS binaries? FreeBSD?

Are all of these inherent and often intended incompatibilities considered breakage?

No. The compositor is the desktop component that implements the Wayland Protocol and puts all of your Wayland clients into one usable output.
That makes sense given:

The compositor is in charge of combining the contents of multiple surfaces into one displayable output.

- Wayland protocol | Wayland Explorer

  1. that being the lack of an xrandr alternative, although wlrandr exists ↩︎

Does that make a difference, somehow?
You say "as we move away from X" in a way that implies that this is necessary. It's golden.
There must be demonstrable Progress in order to call it that.
Wayland is not new, not modern and it is not progress. It is just a different display protocol. It does not progress the GnuLinux desktop. It offers something different in certain ways, but also subtracts from the existing reliable and stable framework.
That is not how we define "progress".

I do not see how this relevant. It is there, now, in spite of those promoting Wayland as a Security Issue implying that it is not there.
Rehashing that it once wasn't makes no difference.

This is also applicable to the "Xorg is old" argument. It does not matter how old it is. It does not matter when it was very first conceptualized.
All that matters is Todays Maintenance of the project. We are using many different projects under that hood that are older than 40 years... Yet no one mentions all that because they are not pushing for an agenda to introduce something else. It's not a problem, until someone wants to claim that it is to get something else.

Your response does not actually address the missing features I pointed out above. It implies that they are fixed - But they are not and most importantly - cannot be fixed. How Wayland works and how it is structured is the very reason why Wayland could not include the discussed features. Otherwise, it would have offered them from the beginning.

This is a Red Herring and in no way does it show that Gnome-Screenshot was incompatible with Wayland, requiring the Gnome Shell integrated tool as part of the Desktop.
However, what I said above is aligned with my statements about Wayland and how Wayland passes things onto the Desktop Environment:

You lost me on this one.
Are you saying that Xorg did not exist for Wayland to break?
It... What?

Your examples are of Windows applications being made for Windows OS. This is irrelevant because they are not made for GnuLinux. Wayland is made for GnuLinux.

Wayland is a replacement for the X11 window system protocol and architecture with the aim to be easier to develop, extend, and maintain.

Wayland is the language (protocol) that applications can use to talk to a display server in order to make themselves visible and get input from the user (a person). A Wayland server is called a "compositor".

Display servers that implement the Wayland display server protocol are also called Wayland compositors because they additionally perform the task of a compositing window manager.

I disagree. TGRush's point is important because it made me realize the potential dangers of applying kernel rules to display servers. The independence of individual projects should be respected.

Since this is a Zorin OS forum, the focus is on how Zorin OS handles Wayland. X doesn't seem to respond well to modern requirements such as multiple displays and scaling. So we can't keep relying on X forever. But now Wayland is not reliable either. Under the circumstances, I believe the compromise of supporting both X and Wayland is reasonable.

I still think it would be less trouble if X were the default, and I would like to see the switch between X and Wayland made more obvious than a small cog, though.

What are these dangers?

You make it sound like this is law and if disobeyed, enforcement would follow.

In violating the Linux Way, independent developers are not punished, nor is there some kind of enforcement that would cramp their style.

It is more like Customer Service. If I say that placing your business model before the customer breaks the first rule of Customer Service, you would be well aware that there is not some Written law by a body of enforcers. It only means that the business in question violated their customers and having been informed of the violation, customers may opt to not do business with that company. It will suffer its own self inflicted wounds.

Xorg handles multiple displays very well. Xorg's architecture is very well-suited for handling multiple displays simultaneously. It allows for configuration of multiple monitors through its configuration files or via tools like xrandr. Xorg can manage multiple displays with different resolutions, orientations, and refresh rates.
Xorg can handle DPI extremely well.
However, I agree that Xorg struggles with Fractional Scaling.
Unlike DPI which is pixel by pixel scaling, Fractional scaling introduces odd variables like 1.5 pixel scaling (How can you have half a pixel?) Wayland is better suited for fractional scaling because, like .svg files, Wayland compositing handles scaling as a vector, rather than pixel-by-pixel approach.

If there were a compromise and user choice was protected, I think the users would not be protesting Wayland so much.
Remember: The developers goal is to be rid of X-windowing/ X server entirely and have only Wayland.

You presented a rule that should be followed in your first post, and when the issue was raised you said it was not the law. I think that is too convenient.

I think that a discussion that covers the merits of the ideas is more productive than putting words into someone else's mouth, then shooting down what they did not say.

In posting your thoughts above about the idea of a rule, I saw that I needed to clarify what that meant. It's a general principle about how to recognize the importance of your user base and not violate them.
When I clarified what it means, your reply suggests a contradiction instead - as if I conveniently changed the meaning.

My Original Post is very clear about the meaning and I stand 100% behind it. I am happy to clarify my posts and thoughts. And I did do so - I changed nothing about what I have said, however.

My experience with Wayland has been mostly positive, with only a few annoyances here and there. But those annoyances don’t exist with Xorg. Without this choice, I would be forced to live with those annoyances until they are fixed, and there would be, of course, no guarantees that this would happen.

Even if we assume that my use case is such an impossibly remote edge case that is not worth the time to implement a fix for it, I still can do without issues using an existing technology, a couple of clicks away. This is the power of freedom of choice, and indeed the real trouble with Wayland.

In short, it’s great that we have Wayland. Competition is good for the consumer. But there needs to be a real viable choice to be made. Gnome has made this very clear: they will stop offering Xorg as an option in the near future. Distributions like Fedora are ahead of schedule on this. And distributions like Zorin OS are implementing this as the default option. Defaults are extremely powerful.

From the user's perspective it's irrelevant why the old screenshot tool, or whatever, doesn't work. It used to work and now it doesn't. The user is being told that the improvements happen under the hood, but those improvements should not come at the cost of the ones over the hood.

If breaking changes need to happen it better be worth the trouble. With Wayland, I'm struggling to see the improvement at the moment; maybe this will change in the future.

To compare this Wayland situation with something we all here are familiar with, the numerous issues that the Zorin OS 17 release is going through, take a look at this recent thread, titled "Why upgrade from 16.3 to 17.1?".
As with Wayland, I've only experienced a few issues here and there with Zorin OS 17 (granted, I only use it in a virtual machine). But, as with Wayland, at the end of the day, I need things to work. I honestly don't recommend people to upgrade to Zorin OS 17 unless they have good reason for it, like the need to run newer versions of a library, kernel some other software. I give the same advice when this comes up even on the latest version if Zorin OS.

In theory, the benefits of Zorin OS 17 more than justify making the upgrade. But, to quote Linus Torvalds:

Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

That is the trouble with Zorin OS 17, and indeed the trouble with Wayland. For as long as there are issues to resolve that impact the user experience, it should remain an alternative to Xorg, not the default, and certainly not the only viable option.

With all that said however, there's something that I'm really curious about regarding the security aspect of Wayland and Xorg. Everywhere I looked online it's stated that Wayland is more secure than Xorg because of how it's designed, and how Xorg allows any running program to read the contents of any window in the display server (and please forgive me if I'm misusing some of these terms).

Only here have I read from Aravisian that this is not the case, at least not anymore. I would really like to know more, but I'm not proficient enough to read directly from the source code. So, is there a proof of concept that demonstrates this or some other source that compares the security mechanisms of Xorg and Wayland?


The Wayland Discussion ... I think it is good when You have the Option to choose between Wayland and X. So, I think the Way Zorin make it to offer both is a good Thing in the Moment.

@zenzen speaks about Gnome and Fedora. Which is an interesting Point here becaue the one thing is a Desktop Environment and the other a whole Distro. As far as I know Gnome wants to kick-off X in Version 48 or so. So, a Distro what wants to use Gnome 48 or higher in the Future mus add X by themself -preinstalled or available in the Repo's.

Fedora wants to kick-off X from the Plasma Version but still deliver it as an Option in the Repo's. I think, when this will happen, it could be a good Indicator how the whole Stuff will work. I'm very interested in that to see what happens with that I must say.

1 Like

Example of initial reports on potential security vulnerability in X-server:

Documentation on Xorg SECURITY extensions (No, I am not yelling. :wink: The name is in all caps.)

Page specific to your question:



Some sites are archived or hosted by Wayback Machine which can complicate google searches.

I am not aware of a site that directly compares with a proof of concept, based on the current software...

1 Like

For the record, a lot of the reason why I chose not to upgrade to OS 17, was due to the talk of them switching to Wayland. All I ever hear about Wayland, is how it breaks the system. And I saw just how many reports that came in from new Zorin OS 17 users, who were reporting problems, due to the use of Wayland.

Also, desktop users have less requirements from an operating system, to utilize the hardware. But laptop users such as myself, who have dual GPU systems, and multiple monitors connected to the laptop via HDMI & Display Port, have much higher level requirements.

Experiencing Linux as I have for the past decade now, I've not had a perfect experience being a laptop user, especially in regards to fractional scaling issues, as I have reported many times on here, since I have been a 4K user.

Having said that however, the reports on how much Wayland breaks the system, and takes away display options, and screws with dual GPU systems, why in the world would I want that? Keep in mind I am a gamer guys, there's a reason why I have an Nvidia GPU in my system. If Wayland breaks the gaming or production experience, why in the world would I want that?

And even though my laptop has a built in screen, unless that laptop is directly in front of me, and within very close range, its useless to me. This is the reason why I use multiple monitor mode, I have one monitor connected via Display Port, and one TV connected via HDMI. If Wayland breaks my ability to use these displays, and or manage them, I ask again, why would I want that?

I agree with Linus Torvalds, I want a system that just works. My user experience shouldn't be broken, because some developer wasn't in the mood, to make their software compatible with modern hardware functionality. I agree that it really is starting to sound like Wayland is becoming like the next Microsoft.

Zorin OS 16.3 is working mostly perfect for me, minus the Zorin Connect APP, which doesn't work at all. As long as I continue to receive security updates until 2025, I see no reason to upgrade at this time, as long as Wayland is breaking systems. Nope, sorry, not going to do it, I need reliability, not incompatibility.

Maybe when Zorin OS 18 comes out, they will have sorted things out by then, so that the user experience doesn't get broken. But until then, I'm not touching Wayland with a 10-foot pole. My philosophy for developers is, stop using users (who never agreed) to beta test your software. Make your software work out of the box, or go home.

This may come as a shock to many experienced Linux users, but most folks don't have the time in modern day, to get their OS software working when it doesn't out of the box. We live busy lives, and have much more important things to do, then to figure out broken garbage out of the gate. Wayland developers, fix your philosophy on development, and fix your Wayland!

At the end of the day, the pro's don't outweigh the cons of usage.

For a fair and balanced discussion, I think it is important to touch on this part.
Over-all, I do agree with much of what you said. What I say below is about analysis, not about disagreement.

What we hear about things is not the same as what we know about things. Relying on the experiences of others is crucial in making decisions for ourselves. Certainly, what we hear is important. It must be analyzed and disseminated, not just taken as Truth™

Many new threads have been started in regards to issues with the release of Zorin OS 17.
In a large number of them, the first question that is asked is whether they are using Wayland or Xorg. This can create bias in what we hear.
We see an issue, then immediately, we see Wayland is the front-runner culprit.
Most of the time, when the user switches, they report no difference.
Some issues are due to Wayland and even to breakage (Complaints about the Gnome-Screenshot tool, for example). Or to having lost features (Where to store the saved screenshot, how to set a delay).
Some users do get a resolution by switching back to Xorg.
But for most of the threads, switching back and forth does not resolve the issue. They seem to relate most strongly to changes made in Gnome 4+, not the display server.

Even if an argument made may provide support for the arguments I have made, it would be unethical for me to allow it to go unchallenged if it needs further scrutiny.

As a gamer, you are Waylands Prime Target Market Audience.
Primarily, it is the gamers that promote Wayland, due to Wayland improving graphical display (Except for Nvidia).

1 Like