Thoughts on Wayland

hvolsomt · 2026-02-14 16:39:14

Hi Archers,

I'm new to Arch and the forums as well - Nice to meet you!

Moving from Windows, I recently installed Arch without a desktop env, and have therefore been looking into X11 and Wayland for the past week.
Most articles that compare the two primarily addresses three topics:

1. Security
2. Performance
3. Compatibility

A problem in X11 that Wayland solves, is cross-talk between applications. This article* mentions three recent CVEs (CVE-2025-62229, CVE-2025-62230, CVE-2025-62231) addressing a 20+ years old issue with X11.
I thought it was a big deal, but then I thought harder:
Has there been any reported incidents that exploited this flaw? Is it at all a problem?
I looked up the CVEs, reported by RedHat, and none of them have been verified by NVD.

Regarding performance, Wayland should outperform X in the sense that application visuals are delivered more directly to the screen.
However, it seems to come at a (high) cost on CPU compared to the benefit on latency. Is that better?

Then the thing that made me speculate on the idea and development of Wayland:
The reason for X being the default display server for so long, as I understand, is because of its extensibility and compatibility.
X11 is very agnostic whereas Wayland puts a whole lot more responsibility on application devs, as the coupling is much more tight.
The key to extensibility and maintainability is abstraction, which is what X11 is all about, so what's the idea with the Wayland architecture?

These questions comes from logic and intuition rather than knowledge on the specifics of the two, so please, feel free to correct me where I'm wrong or inconsiderate.

I hope an expert will take me to school

BR,
Martin

*Albeit generated, but the CVEs are sound.

seth · 2026-02-15 14:13:53

Has there been any reported incidents that exploited this flaw? Is it at all a problem?

* dunno
* yes, if you run malware

Regarding performance, Wayland should outperform X in the sense that application visuals are delivered more directly to the screen.

Not exactly, but the way X11 is used these days you're dealing with a log of pointless roundtrips, theoretically also image upload rather than sharing.
There *is* a valid point in substituting elements of X11 and dropping the more archaic elements of it.
A main wayland benefit is that it dictates a scenegraph what is esp. useful for vsync + compositing matters (though funnily enough, a lot of gamers seem less than happy with what was once the major selling point for wayland and there's a protocol extension/draft/idk to disable that )
There's criticism that the wayland scenegraph is not all that great, but the mere existence removes a lot of variables and headaches.

However, it seems to come at a (high) cost on CPU compared to the benefit on latency. Is that better?

Yesno, wayland effectively equals GBM which requires EGL, so you're using the 3D core of the GPU/IGP and then your average wayland compositor will also (sometimes over-)indulge in the fancy stuff that's cheap to have w/ GL but still more expensive than just not using it.
As a result wayland will typically result in less battery time than (uncomposited) X11

so what's the idea with the Wayland architecture?

As for replacing X11 at all?
The X11 architecture (designed for a mainframe/terminal environment) was deemed dated in the late 90ies early 2000's
There's is and has always been reason to replace that w/ something that's more geared towards local clients (process and output on the them system)

As for waylands specifically?
Context isolation seems to have been a huge concern (like in browsers or phone apps from an app-store)

As for the glaring omissions on anything that could bridge that to suit the requirements of a normal desktop system?
One shall not explain w/ conspiracy theories what can sufficiently be explained w/ incompetence, but looking at the compatibility mess and the role gnome and redhat had in pushing wayland…

https://gitlab.gnome.org/GNOME/adwaita- … te_2010537
"It serves GNOME core apps." (This has been breaking and crashing random clients trying to load now absent cursors)

Compatibility is not and has never been a goal but a stain with anything redhat/fedora does and I'd not be surprised if that's been driving the glaring shortcomings of the wayland protocol.
Relying on incompatible, proprietary and unstable NIH extensions might be more a feature than a bug. At least to some actors.
¯\_(ツ)_/¯

hvolsomt · 2026-02-18 14:27:43

yes, if you run malware

Uff, that's probably true for a plethora of software - Better avoid running malware then.

the way X11 is used these days you're dealing with a log of pointless roundtrips, theoretically also image upload rather than sharing.

Bad driver impl or env configuration? And "image upload" referring to how X11 is streaming the image?

more geared towards local clients

Okay, I guess they achieved that. However, why put so much effort into compositioning (using the GPU and all), when GPU heavy applications usually run full screen? The whole (visible) framebuffer would be handed to that app anyway - At least to me, that would seem to be the general experience.

So on one hand, we have an outdated model that is well coded, and on the other, a mess which better fits the modern use case - They didn't do much with that low hanging fruit, but I guess that's the epidemy of modern, corporate software: quick and dirty. Did they monetize it yet?...

I'll probably stick with X11 for now, and see if I can avoid too much overhead - I'm intrigued by remote rendering anyways, so there goes my local client gearing.

Thx for the reply, seth!

seth · 2026-02-18 14:37:55

Bad driver impl or env configuration?

Bad century - X11 was designed for a different kind of infrastructure.
"Network transparency" wasn't some feature, it was the architecture.

You're btw. still running this kind of thing but on a different protocol.
And you're probably currently staring at it

Edit:
Might be interesting, https://arcan-fe.com/2026/01/26/arcan-e … rent-webs/

Last edited by seth (2026-02-18 14:38:39)

lilydjwg · 2026-02-18 15:13:39

hvolsomt wrote:

Regarding performance, Wayland should outperform X in the sense that application visuals are delivered more directly to the screen.
However, it seems to come at a (high) cost on CPU compared to the benefit on latency. Is that better?

I get double graphical performance for web browsers after switching from Xorg to Wayland, and get rid of the annoying tearing that showed up everywhere with Xorg's modesetting driver.

hvolsomt wrote:

Then the thing that made me speculate on the idea and development of Wayland:
The reason for X being the default display server for so long, as I understand, is because of its extensibility and compatibility.
X11 is very agnostic whereas Wayland puts a whole lot more responsibility on application devs, as the coupling is much more tight.
The key to extensibility and maintainability is abstraction, which is what X11 is all about, so what's the idea with the Wayland architecture?

The reason is because nothing was replacing it. X has been aging for years.

X's philosophy is to provide mechanism, not policy. That is why X is so extensive, to the point that clients no longer use a lot of things X provides except for input, output and IPC. No more server-side font rendering. No more a hierarchy of windows. Clients render and manage these themselves. And I heard that for performance reasons many programs even bypass the image uploading roundtrip and talk directly to the display card using some extension.

Another example of "extensibility" is the input method (which is needed to input Chinese or Japanese etc). XIM is so bad that well-maintained GUI frameworks bypass it via their own plugins and D-Bus protocols.

X achieves compatibility by being old, so that applications and window managers finally converge to support the same set of features, and other server implementations except Xorg either died or have very limited usage. Did you ever wonder why the DISPLAY value is sometimes written as :0.0 instead of :0? If you used a multiple screen feature whose name I no longer remember, you would see :0.1 etc. But nobody cares it anymore.

Maintainability? Lost in all those extensions. I don't know a way to trace X traffic even after years with it, but I know how to put WAYLAND_DEBUG=1 here and there to debug Wayland applications soon after switching to it.

One result of not caring policy is that there is no secure screen locker. You make a fullscreen window and put it above all others. That's it. But what if there are two of them? What if the screen locker dies?

seth · 2026-02-18 15:38:01

I get double graphical performance for web browsers after switching from Xorg to Wayland

Very most likely been double-syncing (in the browser and your DEs compositor) - there's no realistic performance dividend of that scale.

One result of not caring policy is that there is no secure screen locker. You make a fullscreen window and put it above all others. That's it.

The common approach was/is to grab input and/or server.

What if the screen locker dies?

You're gonna be fucked regardless of display server.

XIM is so bad that well-maintained GUI frameworks bypass it via their own plugins and D-Bus protocols.

I'd not bring up IME in defense of wayland…

If you used a multiple screen feature whose name I no longer remember, you would see :0.1 etc.

https://wiki.archlinux.org/title/Multih … te_screens - largely an artifact of ancient hardware but you still get to use multiple (randomly incompatible) GPUs driving outputs in the same system.

I don't know a way to trace X traffic even after years with it, but I know how to put WAYLAND_DEBUG=1 here and there to debug Wayland applications soon after switching to it.

https://man.archlinux.org/man/xev.1
WAYLAND_DEBUG is a feature of libwayland, this approach cannot work w/ systems designed for remote connections.

Docbroke · 2026-02-18 17:33:19

Wayland may be better on newer devices.
On my new laptop (Asus Rog Flow Z13 with AMD Ryzen AI Max 390 ), playing videos in X is like watching images, that only change when I use arrow key in mpv. In wayland videos play perfectly.

Last edited by Docbroke (2026-02-18 17:34:40)

seth · 2026-02-18 18:08:24

Sounds more like a bug in your DEs compositor or (less likely) mpv or maybe misconfigured xf86-video-amdgpu.
Please open a thread if you care - no display server is the limiting factor when rendering videos at 24-60fps
Let alone on new hardware.

-MacNuke- · 2026-02-18 18:55:42

In the end it does not really matter. X11 is dead. GNOME dropped support. KDE will drop support soon. GTK 5 will drop support. Qt will probably also drop support in the future too. And with both of them pretty much every app out there at some point. Only a matter of time when Chrome and FireFox will follow.

lilydjwg · 2026-02-19 07:22:13

seth wrote:

One result of not caring policy is that there is no secure screen locker. You make a fullscreen window and put it above all others. That's it.
The common approach was/is to grab input and/or server.

Yes. Once there was a bug somewhere and I tried to close windows one by one to figure out which grabbed my mouse and didn't release it. And when there is a grab ongoing, the screen locker won't work. (Remember to dismiss any popup menus before lock the screen and leave. Or better, wait until the lockscreen shows up.)

seth wrote:

What if the screen locker dies?
You're gonna be fucked regardless of display server.

With a good implementation of Wayland compositor, the compositor will lock the screen anyway until you either spawn the locker in some way (e.g. via another tty or ssh), or just reboot. At least it is not unlocked by a crash.

seth wrote:

I don't know a way to trace X traffic even after years with it, but I know how to put WAYLAND_DEBUG=1 here and there to debug Wayland applications soon after switching to it.
https://man.archlinux.org/man/xev.1
WAYLAND_DEBUG is a feature of libwayland, this approach cannot work w/ systems designed for remote connections.

I know xev. It is good for debugging input devices, but not useful to debug GUI applications when they mess up with the display protocol. Yes, WAYLAND_DEBUG is implemented by libwayland, and smithay has it too. I don't know why libxcb doesn't have an equivalent.

seth wrote:

no display server is the limiting factor when rendering videos at 24-60fps

One of the most important reason for me to switch to Wayland was to play YouTube 4K / 1080p60 without significant frame loss (it is an old laptop). Maybe the limiting factor was the standalone X11 compositor (picom; despite unredirect should be taking effect in fullscreen), but anyway Wayland solved the problem.

hvolsomt · 2026-02-19 14:02:04

seth wrote:

You're btw. still running this kind of thing but on a different protocol.
And you're probably currently staring at it

I'm guessing Windows is the name you're looking, and you are correct That's exactly why I'm here.
Thanks for the article, btw.

lilydjwg wrote:

The reason is because nothing was replacing it. X has been aging for years.

Isn't that just a fact rather than a reason?

Maybe the way X is working presently is dead, but the fundamental idea of event based I/O is very much alive - We use it everywhere.

Delegating responsibility to clients (i.e. making the model more concrete), is a 'smell'. Which is why I don't get the whole idea behind the Wayland architecture.

Regarding security, we also do i the X way everywhere. See: "tcp/udp". It is very doable with a single transport layer. Yes, I know it doesn't translate perfectly to this scenario, but there is some resemblance, from my perspective.

Regarding performance, it sounds like we have our individual experiences, which is expected given our entirely different configurations. I think that, for me, the bottom line is that I am willing to sacrifice some performance for convenience - If that is what I'm doing by using X... Time will tell

seth · 2026-02-19 15:11:53

lilydjwg wrote:

At least it is not unlocked by a crash.

If that's a concern you'd just handle the lockers exit code and if it's anything but 0, 3 or 15 take down the session (which is more controlled than the WM/display server crashing w/ the locker)
The thing where display server and various interactive and arbitrarily complex functions are stuffed into the same process is quite frankly an unimpressive design - notably since the common X11 practice is continued and clients just commit suicide when they lose the display server.

lilydjwg wrote:

I don't know why libxcb doesn't have an equivalent.

seth wrote:

this approach cannot work w/ systems designed for remote connections.

You could only properly debug one end of the connection - monitoring the traffic was otherwise commonly done via socket sniffing.

lilydjwg wrote:

Maybe the limiting factor was the standalone X11 compositor

seth wrote:

lilydjwg wrote:
I get double graphical performance for web browsers after switching from Xorg to Wayland
Very most likely been double-syncing (in the browser and your DEs compositor) - there's no realistic performance dividend of that scale.

---------------

hvolsomt wrote:

I'm guessing Windows is the name you're looking

No. Your browser

lilydjwg · 2026-02-20 06:39:02

seth wrote:

lilydjwg wrote:
At least it is not unlocked by a crash.
If that's a concern you'd just handle the lockers exit code and if it's anything but 0, 3 or 15 take down the session (which is more controlled than the WM/display server crashing w/ the locker)

This is a brilliant idea that I never heard of!

seth wrote:

The thing where display server and various interactive and arbitrarily complex functions are stuffed into the same process is quite frankly an unimpressive design - notably since the common X11 practice is continued and clients just commit suicide when they lose the display server.

This reminds me of another process that does too many important things....

Anyway Wayland clients can survive and reconnect when the compositor is gone. I heard that Qt has implemented it, but sadly GTK doesn't.

GTK 2 had the ability to switch between X servers, so there was potential that it could "switch" to the new server when the current one died, but I haven't seen any actual program using this feature.

seth wrote:

You could only properly debug one end of the connection - monitoring the traffic was otherwise commonly done via socket sniffing.

How do I sniff a UNIX domain socket? And are there tools dissecting the protocol (e.g. a Wireshark plugin)?

seth · 2026-02-20 16:38:52

I heard that Qt has implemented it, but sadly GTK doesn't. GTK 2 had the ability to switch between X servers

As indicated this is unfortunately a largely neglected feature of both protocols, so it's borderline irrelevant wrt the ability to restart the display server w/o killing your clients
The only reliable player here is tmux

How do I sniff a UNIX domain socket?

https://man.archlinux.org/man/socat1.1.en
https://mivehind.net/2018/04/20/sniffin … n-sockets/

And are there tools dissecting the protocol (e.g. a Wireshark plugin)?

https://wiki.wireshark.org/X11

Arch Linux

#1 2026-02-14 16:39:14

Thoughts on Wayland

#2 2026-02-15 14:13:53

Re: Thoughts on Wayland

#3 2026-02-18 14:27:43

Re: Thoughts on Wayland

#4 2026-02-18 14:37:55

Re: Thoughts on Wayland

#5 2026-02-18 15:13:39

Re: Thoughts on Wayland

#6 2026-02-18 15:38:01

Re: Thoughts on Wayland

#7 2026-02-18 17:33:19

Re: Thoughts on Wayland

#8 2026-02-18 18:08:24

Re: Thoughts on Wayland

#9 2026-02-18 18:55:42

Re: Thoughts on Wayland

#10 2026-02-19 07:22:13

Re: Thoughts on Wayland

#11 2026-02-19 14:02:04

Re: Thoughts on Wayland

#12 2026-02-19 15:11:53

Re: Thoughts on Wayland

#13 2026-02-20 06:39:02

Re: Thoughts on Wayland

#14 2026-02-20 16:38:52

Re: Thoughts on Wayland

Board footer