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.
“In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported 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. It’s all happening!”
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
eglCreatePbufferSurfacewith 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.
That’s my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren’t relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let’s say wlroots will implement this but others can decide otherwise. And for those the app won’t run.
Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn’t care having these so I doesn’t care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.
Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.
Do I see it wrong?
Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.
The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you’re running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don’t need, etc.
Oh and just for the record that doesn’t mean that you can’t undock the terminal: Just ask the compositor you’re running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that’s only standardised for the crash case there’s no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.
The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it.
So there’s a Wayland hope for systemd-afflicted boxes and their cults.
You anti-systemd folks are so insufferable.
Oh boy, the Phoronix’s comment section 💀
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.
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.
One of the specific issues from those who’ve worked with Wayland and is echoed here in Nate’s other post that you mentioned.
Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction.
I tend to disagree. Had say the XDG stuff been specified in protocol, implementation of handlers for some of that XDG stuff would have been required in things that honestly wouldn’t have needed them. I don’t think infotainment systems need a concept of copy/paste but having to write:
Some_Sort_Of_Return handle_copy(wl_surface *srf, wl_buffer* buf) { //Completely ignore this return 0; } Some_Sort_Of_Return handle_paste(wl_surface *srf, wl_buffer* buf) { //Completely ignore this return 0; }Is really missing the point of starting fresh, is bytes in the binary that didn’t need to be there, and while my example is pretty minimal for shits and giggles IRL would have been a great way to introduce “randomness” and “breakage” for those just wanting to ignore this entire aspect.
But one of those agree to disagree. I think the level of hands off Wayland went was the correct amount. And now that we have things like
wlrootseven better, because if want to start there you can now start there and add what you need. XDG is XDG and if that’s what you want, you can have it. But if you want your own way (because eff working nicely with GNOME and KDE, if that’s your cup of tea) you’ve got all the rope in the world you will ever need.I get what Nate is saying, but things like XDG are just what happened with ICCCM. And when Wayland came in super lightweight, it allowed the inevitably of XDG to have lots of room to specify. ICCCM had to contort to fit around X. I don’t know, but the way I like to think about it is like unsalted butter. Yes, my potato is likely going to need salt and butter. But I like unsalted butter because then if I want a pretty light salt potato, I’m not stuck with starting from salted butter’s level of salt.
I don’t know, maybe I’m just weird like that.
I don’t think infotainment systems need a concept of copy/paste but having to write:
Having lived through the whole “phones don’t need copy and paste debate”, which fortunately got solved by now having it everywhere I’m in the camp “just stick that everywhere, just in case somebody might use it one day”
Nate Graham acknowledges current gaps in Wayland support but on the matter of “Wayland breaks everything” isn’t really the right perspective
That’s rather disingenuous. It’s meant to be a replacement for X11. So it does break things.
deleted by creator
As railways were a replacement for canals.
It was not the railways that broke the barge. But the companies expecting to gain the advantages without adapting there transportation.
Replace not upgrade.
PS i still use canals. Bur do not blame the raIlway for not fitting my boat.
Railways are not a “replacement” for canals.
Lol. Learn your history.
In the UK railways very much were a replacement for canals.
Both being built to transport good accross the nation.
Lol. Learn your history.
Don’t be shitty.
Yeah sorry. But when you look at the events building europeen railways. More so in the UK as we had a huge canal system built in a few decades. But most of Europe denser areas.
Railways were very much a replacement for the to slow canal system.
Canals built a huge industry allowing manufacturers to ship goods to cities while shipping resources from the mines and farms etc.
But industries like meat fish milk and strongly enough market gardening (fresh flowers) were very limited to local areas before the railways. Took off hugely when the railways intentionally set up in direct competition to the canals.
Canals survived for a while moving the slower stuff. But started needing to redesign to support bigger and more boats faster. Before finally closing down.
The UK and most of Europe rebuilt/renovated them as a leasure activity from the 1950s. But most of the late 1800 to early 1900s railways vcompanies actually worked to replace and put canal companies out of business.
Passenger rail really was not a big thing untill about the 1920s.
We’re getting well away from the topic now. It depends on what you mean by “replace”. Railways and canals exist side-by-side as different solutions to similar problems - sure. And some railways have replaced some canals. But the panama canal will not be replaced by a railroad for example. It couldn’t do the same job. The pros/cons of each option depends on many factors.
The analogy is poor for comparing software. Linux distros will likely replace X11 with Wayland over time. To do the same thing that X11 was doing. It will be replaced “in place”. The very same thing you were using with X11 will now need to work on Wayland. This would be like running your barges on the railroad? Maybe? Depending on how you squint?
I wouldn’t expect my barge to work on the railroad. I do expect that Firefox will run on Wayland after having used it on X11 for 20 years.
But as a user of a barge if you needed wanted to use railways. Because they are faster. It would be the barge maker or a new train maker you would look at. Not the railway.
Just like canals X11 still exists. And is still being developed. It has its limitations but some applications are choosing not to port. Because like barge makers. They simply do not see the need. Or merit.
If the makers of railways insisted that all current users agents had to work on them without adaption. Many of the advantages would no longer be there.
Just as if waylaid did not expect Firefox et al to adapt to its methods. The security and other advantages they seek would not be practice.
Waylaid is a replacement. Not an upgrade.
(PS yeah living in the UK replace canal with inland waterways navigation. Tends to be how we think of it. As they are such a huge part of our industrial history. I forget the US really never went through that part of europeen industrial development. Your example is a fairly unique and modern by comparison, it dose not link to any network. Where as the inland waterways accross the UK and parts of Europe were a linked inferstructure like our railways. When the railways in Europe were built. They were very much seen as a replacement to our existing canal system. By both the corperations set up to build the inferstructure and the media of the time. It is literally a part of our industrial history thought is schools here. As so much of our culture and industrial revolution is built around the events)
Soo support for something like synergy would be great!
Input Leap (fork of a fork of synergy) supports Wayland under gnome, although it seems there are a few bugs remaining.
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.
Trying to gaslight others? nice
Wayland developer says X11 is bad, not Wayland
