Alternatively, instead of reading a Phoronix article that has a couple of short snippets from a much longer blog post, you can read the original blog post yourself to see the full context.

Edit: Also, it is worth noting that the author of the original blog post had previously written another relatively recent post criticizing the way in which Wayland was developed, so it’s not like they are refusing to see its problems.

Over on Nate’s other blog entry he indicates this:

The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible

And I think this is something people tend to forget. X11 as a protocol is complex and writing an implementation of it is difficult to say the least. Because of this, we’ve all kind of relied on Xorg’s implementation of it and things like KDE and GNOME piggyback on top of that. However, nothing (outside of the pure complexity) prevented KWin (just as an example) implementing it’s own X server. KWin having it’s own X server would give it specific things that would better handle the things KWin specifically needed.

Good parallel is how crazy insane the HTML5 spec has become and how now pretty much only Google can write a browser for that spec (with thankfully Firefox also keeping up) and everyone is just cloning that browser and putting their specific spin to it. But if a deep enough core change happens, that’s likely to find its way into all of the spins. And that was some of the issue with X. Good example here, because of the specific way X works an “OK” button (as an example) is actually implemented by your toolkit as a child window. Menus those are windows too. In fact pretty much no toolkit uses primitives anymore. It’s all windows with lots and lots of text attributes. And your toolkit Qt, Gtk, WINGs, EFL, etc handle all those attributes so that events like “clicking a mouse button” work like had you clicked a button and not a window that’s drawn to look like a button.

That’s all because these toolkits want to do things that X won’t explicitly allow them to do. Now the various DEs can just write an X server that has their concept of what a button should do, how it should look, etc… And that would work except that, say you fire up GIMP that uses Gtk and Gtk has it’s idea of how that widget should look and work and boom things break with the KDE X server. That’s because of the way X11 is defined. There’s this middle man that always sits there dictating how things work. Clients draw to you, not to the screen in X. And that’s fundamentally how X and Wayland are different.

I think people think of Wayland in the same way of X11. That there’s this Xorg that exists and we’ll all be using it and configuring it. And that’s not wholly true. In X we have the X server and in that department we had Xorg/XFree86 (and some other minor bit players). The analog for that in Wayland (roughly, because Wayland ≠ X) is the Compositor. Of which we have Mutter, Clayland, KWin, Weston, Enlightenment, and so on. Which that’s more than just one that we’re used to. That’s because the Wayland protocol is simple enough for these multiple implementations.

The skinny is that a Compositor needs to at the very least provide these:

• wl_display - This is the protocol itself.
• wl_registry - A place to register objects that come into the compositor.
• wl_surface - A place for things to draw.
• wl_buffer - When those things draw there should be one of these for them to pack the data into.
• wl_output - Where rubber hits the road pretty much, wl_surface should display wl_buffer onto this thing.
• wl_keyboard/wl_touch/etc - The things that will interact with the other things.
• wl_seat - The bringing together of the above into something a human being is interacting with.

And that’s about it. The specifics of how to interface with hardware and what not is mostly left to the kernel. In fact, pretty much compositors are just doing everything in EGL, that is KWin’s wl_buffer (just random example here) is a eglCreatePbufferSurface with other stuff specific to what KWin needs and that’s it. I would assume Mutter is pretty much the same case here. This gets a ton of the formality stuff that X11 required out of the way and allows Compositors more direct access to the underlying hardware. Which was pretty much the case for all of the Window Managers since 2010ish. All of them basically Window Manage in OpenGL because OpenGL allowed them to skip a lot of X, but of course there is GLX (that one bit where X and OpenGL cross) but that’s so much better than dealing with Xlib and everything it requires that would routinely require “creative” workarounds.

This is what’s great about Wayland, it allows KWin to focus on what KWin needs, mutter to focus on what mutter needs, but provides enough generic interface that Qt applications will show up on mutter just fine. Wayland goes out of its way to get out of the way. BUT that means things we’ve enjoyed previously aren’t there, like clipboards, screen recording, etc. Because X dictated those things and for Wayland, that’s outside of scope.

Oh boy, 102 comments. Knowing Phoronix, I bet those are a treat to read.

Oh boy, the Phoronix’s comment section 💀

It’s super impressive to see Wayland having its big breakthrough moment. I remember reading about Wayland 10 years ago and worrying it was going to end up as a dead project.

Wayland developer says X11 is bad, not Wayland

Anecdote, I know, but for my use cases, Wayland just isn’t there yet- I wind up with far more random bugs and less battery life. I don’t pretend to know why, I’m a pleb non-developer, but until that’s resolved I’m still stuck on X. I’d love to use the new shiny thing of The Future™, but not at the cost of stability and usability.

I don’t see why we need convincing that Wayland’s better. Most Linux users either use it currently or are possibly looking to switch in the future. The other people who are not are likely going to use X for eternity

I love Wayland until I don’t. I honestly don’t think about it, it gets out of my way and my system is stable, until I go to use something like scrcpy that just doesn’t work at all. Luckily, the amount of things that straight up don’t work is shrinking.

Wayland doesn’t support Nvidia GPUs yet

I’m sorry, my bad, I was unaware.

Nvidia GPUs don’t support Wayland yet. As Linux Torvalds would say, “NVidia, Fuck You”

This is the best summary I could come up with:

Well known KDE developer Nate Graham is out with a blog post today outlining his latest Wayland thoughts, how X11 is a bad platform, and the recent topic of “Wayland breaking everything” isn’t really accurate.

Nate Graham acknowledges current gaps in Wayland support but on the matter of “Wayland breaks everything” isn’t really the right perspective: "Look, if I said, “Linux breaks Photoshop; you should keep using Windows!” I know how you’d respond, right?

You’d say “Wait a minute, the problem is that Photoshop doesn’t support Linux!” And you’d be right.

Because there’s nothing Linux can do to ‘un-break’ Photoshop; Adobe needs to port their software, and they simply haven’t done so yet.

This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore.

For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on.

The original article contains 395 words, the summary contains 187 words. Saved 53%. I’m a bot and I’m open source!

Trying to gaslight others? nice

Soo support for something like synergy would be great!

Wayland on an Intel iGPU runs flawlessly and has for several years. However, that’s a matter of drivers. AMD is in the forefront regarding having dGPU support, while NVIDIA is playing catch-up.

In any case, the future is bright.

Because Wayland is only a protocol and you write the platform yourself (be it badly or not).

Would be cool if the reference implementation (Weston) were not an unusable monolith but a small plugin-based thing.