[gsliepen]

A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinventing the wheel, and each of them has to deal with all the quirks of the graphics drivers. I think this is a big problem with the architecture of Wayland. There really should be a standard library that all desktops use. Wlroots aims to be one, but I don't see Gnome and KDE moving to it anytime soon.

[PunchyHamster]

X.org picked the right level of abstraction (even if implementation could use a rewrite). No WM should care about handling raw inputs or forced to be proxy between driver and the app for the output (it could be, if it needed/wanted, but there is no reason to add another layer of abstraction and cycle-wasting for most use cases). And it shows in complexity and even in power use. Wayland basically failed to learn the lessons from X11

[dotancohen]

That's easy to say in hindsight. It is only with the specific failures of Wayland that we see which lessons it could have learned from X11.

[secure]

No, the lesson of “separate display server from window manager” was very clear when Wayland was started. People have been discussing this over the years ever since. (See also “client-side decorations” for another part of this issue that was heavily discussed.)

[mananaysiempre]

I seem to remember reading in an old paper (1990s?) that the asynchronous nature of the connection between the X server and the window manager results in essentially unfixable protocol-level races.

[immibis]

Wayland has a philosophy of "every frame is perfect", which means fixing every race condition. However, X11 doesn't have this philosophy. If the window manager is slow and doesn't respond to a notification that a window has been resized, drawing the new window content over the old borders is the correct thing to do. What sense does it make to freeze the whole display just for a window border?

Similarly, tearing gets pixels to the screen faster.

[silon42]

Reacting somehow to user input, even if not perfect, is more important for me... That's why we have HW cursors, and frame interpolation in games, etc...

[speed_spread]

Perfect frames is what Mac and Windows provide and what Linux should also aim for. Border tearing is a display bug, correctness should come first, Wayland's approach is right. X was designed for CPU and IO constraints that no longer apply. _Graceful_ degradation of slow UI should lower the frame rate, not compromise rendering of individual frames.

[Maskawanian]

Tearing and hidpi is why I left Linux for Windows between 2012 ans 2022. Once wayland was good enough I returned. Tearing is awful, and should be opt in (which wayland provides), not opt out.

[mananaysiempre]

The races I recall being described were substantially worse, but that’s largely beside my point.

My point is that, now that bare fillrate and framebuffer memory haven’t been a limiting factor for 15 to 20 years, it is a reasonable choice to build a desktop graphics system with the invariant of every frame being perfect—not even because of the user experience, but because that allows the developer to unequivocally classify every imperfect frame as a bug. Invariants are nice like that. And once that decision has been made, you cannot have asynchronous out-of-process window management. (I’m not convinced that out-of-process but synchronous is useful.) A reasonable choice is not necessarily the right choice, but neither is it moronic, and I’ve yet to see a discussion of that choice that doesn’t start with calling (formerly-X11) Wayland designers morons for not doing the thing that X11 did (if in not so many words).

To be clear, I’m still low-key pissed that a crash in my desktop shell, which was deliberately designed as a dynamic-language extensibility free-for-all in the vein of Emacs or TeX, crashes my entire graphical session, also as a result of deliberate design. The combination of those two reasonable decisions is, in fact, moronic. But it didn’t need to be done that way even on Wayland.

[ptx]

Maybe this one [1] from 1987? It says:

> There are many race conditions that must be dealt with in input and window management because of the asynchronous nature of event handling. [...] However, not all race conditions have acceptable solutions within the current X design. For a general solution it must be possible for the manager to synchronize operations explicitly with event processing in the server. For example, a manager might specify that, at the press of a button, event processing in the server should cease until an explicit acknowledgment is received from the manager.

[1] https://web.mit.edu/6.033/2006/wwwdocs/papers/protected/xwin...

[mananaysiempre]

I went and checked, and it was an SPE article from 1990[1]: “Why X is not our ideal window system” by Gajewska, Manasse, and McCormack. Section 3 has extensive diagrams of various races, including ones between clients and the window manager. Was even discussed here at one point[2], it turns out. Where I came across it I’m not sure (on X.org[3] possibly?).

[1] https://dx.doi.org/10.1002/spe.4380201409, https://people.freedesktop.org/~ajax/WhyX.pdf or http://os.4uj.org/WhyX.pdf

[2] https://news.ycombinator.com/item?id=15120308

[3] https://x.org/wiki/XorgDeveloperDocumentation/

[DonHopkins]

I covered that in the X-Windows Disaster chapter of the Unix Haters handbook, and many HN posts, and other articles. So it's quite disappointing and underwhelming that Wayland failed to learn or apply any of these lessons. All this stuff was widely discussed long before Wayland was designed in reaction to X11, without considering any alternatives than Windows and Mac.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

https://news.ycombinator.com/item?id=22491561

https://news.ycombinator.com/item?id=15035419

https://news.ycombinator.com/item?id=28522534

https://news.ycombinator.com/item?id=44045304

https://news.ycombinator.com/item?id=29964737

https://news.ycombinator.com/item?id=15327339

https://www.donhopkins.com/home/catalog/unix-haters/x-window...

https://blog.dshr.org/2024/07/x-window-system-at-40.html

David Rosenthal wrote:

>There is a certain justice in The UNIX-HATERS Handbook's description of my efforts:

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.

If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view.

As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.

[antisol]

I just wanted to say thanks - I read the unix-hater's handbook about 15 years ago and it taught me a LOT, maybe even changed my life. The chapter on X was particularly memorable and entertaining. Thanks!

[someguyiguess]

Your memory is insanely impressive to remember such an obscure article from so long ago.

[charcircuit]

>That's easy to say in hindsight

That's an easy way to excuse bad design. Look at the designs of other operating systems designed by professionals and you won't see windows managers having to handle raw inputs or being in the same process as the compositor.

[the_why_of_y]

Examples of other operating systems allegedly not designed by professionals:

https://en.wikipedia.org/wiki/Desktop_Window_Manager

The Desktop Window Manager is a compositing window manager, meaning that each program has a buffer that it writes data to; DWM then composites each program's buffer into a final image.

https://web.archive.org/web/20040925095929/http://developer....

The Quartz Compositor layer of Mac OS X comprises the window server and the (private) system programming interfaces (SPI) implemented by the window server. In this layer are the facilities responsible for rudimentary screen displays, window compositing and management, event routing, and cursor management.

The window server is a single system-wide process that coordinates low-level windowing behavior and enforces a fundamental uniformity in what appears on the screen. It is a lightweight server in that it does not do any rendering itself, but instead communicates with the client graphics libraries layered on top of it. It is “agnostic” in terms of a drawing model.

The window server has few dependencies on other system services and libraries. It relies on the kernel environment’s I/O Kit (specifically, device drivers built with the I/O Kit) in order to communicate with the frame buffer, the input infrastructure, and input and output devices.

[charcircuit]

Window management on Windows is done by Explore which talks to DWM where the underlying windows live.

Window management on MacOS is done by Dock which talks to Quartz Compositor where the underlying windows live.

[abhinavk]

You are conflating Window Manager with Task Switcher programs.

[exe34]

No, this was a major point of discussion right at the start. They chose to ignore it.

[naikrovek]

They should have looked at Plan9 and the Rio window manager there.

I don’t know how GPU acceleration would have fit in, but I bet it would have been trivial provided the drivers were sufficient.

All of Rio in Plan9 is 6K lines of code and it’s a more powerful display protocol and window manager (all of the fundamentals are there but none of the niceties) than anything else I’ve ever seen.

The defacto way to remote into a Plan9 system from any OS even today is to use a client side program which implements it all the same way Plan9 does.

[tuna74]

The beauty with Free Software and Linux distros is that "they" don't have to do it, anyone who wants to (including you!) can do it.

[Oxodao]

In theory. In practice, every app is designed for X11 or Wayland, building your own means you need to follow what most people use anyway if you want to have any working app on your system, or rewrite every app yourself

[exe34]

yep, that's why I stuck with x11, as it still does everything I need it to do. it's actually never crashed since they stopped fixing it.

[hakfoo]

Wayland should have been been a research project rather than a full replacement for X11. Build it as a proof of concept implementation with just enough functionality that enthusiasts can get it up and running and add to the conversation early on. Then when you build the real X11 killer you can say "we know people want media keys and screen sharing/capture to Just Work so they're table stakes" and "the hardware-support side of a compositor is a big lift, so maybe we delegate that away from the code that positions windows and draws menus on the screen"

[StopDisinfo910]

Disagree.

You need this amount of control to be able to properly filter and secure things. Wayland actually learnt that from X security extensions failure.

To me, Wayland failures are more on the organisational and change management part. In inside, it would probably have been better to provide a core library rather a reference implementation. Also, a lot of pieces needed to fall into place once the ball started rolling and some of them like PipeWire took quite some time to be ready.

The sorry fragmentation and complete unwillingness to work together of the various Linux DE also didn't help. I think Gnome constant NIH syndrome and overall capture of Freedesktop has a lot to do with where we are.

[hsbauauvhabzb]

I think the lack of base abstraction layer was pretty obvious from the start.

[the_why_of_y]

Since this is a Wayland thread, obviously the problem is a lack of a common implementation, which deviates from UNIX tradition.

For those who want to complain how lack of choice between multiple implementations is an obvious problem and deviates from UNIX tradition, please wait until the next systemd thread.

[hsbauauvhabzb]

Weird strawman, but you do you.

[DonHopkins]

It also failed to learn the lessons it should have learned from NeWS.

[TacticalCoder]

> Wayland basically failed to learn the lessons from X11

To me the biggest issue of Wayland is that it aimed, on purpose, to imitate Windows or OS X or any GUI that is not built on the idea of a client/server protocol.

From TFA:

> I’ll also need a solution for running Emacs remotely.

If only there was something conceived from the start as a client/server display protocol...

[gspr]

For remote applications, Waypipe works fine for me at least.

[hulitu]

> To me the biggest issue of Wayland is that it aimed, on purpose, to imitate Windows

Freedesktop.org really looks like a Microsoft subsidiary. Only if they could learn from the past.

[jauntywundrkind]

The blanket statement "right level of abstraction" betrays a pretty narrow minded view. Right abstraction for what?

The big thing to me is, Wayland servers have way way less responsibility than X. X had a huge Herculean task, of doing everything the video card needed. It was a big honking display server because it took up a huge chunk of the stack to run a desktop.

Wayland servers all use kernel mode setting kernel buffers, so much more. So much of the job is done. There is a huge shared code base that Wayland has that X never had, good Kernel's with actual drivers for GPUs.

If we wanted one stable platform that we could not innovate on, that was what it was and we all had to deal with it... We'd all just use Mac. punchyHamster is saying The Cathedral is the right model and The Bazaar is the bad model, of the famous Cathedral vs Bazaar.

But the model really does not enable fast iteration & broader exploration of problem spaces. The ask doesn't even make sense: there are incredibly good libraries for making Wayland servers (wlroots, smithay, more). And they're not always even huge, but do all the core protocols. Some people really want professional industrial direct software that they never have to think about that only works one way and will only evolve slowly and deliberately. I'm thankful as fuck Wayland developers aren't catering to these people, and I think that's the wrong abstraction for open source and the wrong excitement to allow timeless systems to be built grown and evolved. We should avoid critical core dependencies, so that we can send into the future, without being tied to particular code-bases. That seems obvious and proposing otherwise to consign ourselves to small limp fates.

[gf000]

> No WM should care about handling raw inputs or forced to be proxy between driver and the app for the output

But.. why? How many WM is feasible to have? Is it really an area where we want a "wide waist"? Should a WM be its own thing? Why not just make it an extension/plugin of a desktop environment, and have only a few of the latter? Being a library call is more efficient and easier to maintain, over maintaining an IPC API (especially that with X, X is just a dumb proxy to the compositor).

> And it shows in complexity and even in power use

You surely mean that X is more complex and has a higher power use, right?

[imtringued]

The real problem with post X compositors is that the Wayland developers assumed that the compositor developers will develop additional working groups (an input protocol, a window management protocol, etc) on top of the working group that exclusively focuses on display aka Wayland. Wayland was supposed to be one protocol out of many, with the idea being that if Wayland ever turns out to be a problem it is small in scope and can be replaced easily.

People who are thinking of a Wayland replacement at this stage, mostly because they don't like it, will waste their time reinventing the mature parts instead of thinking about how to solve the remaining problems.

There is also a misunderstanding of the ideology the Wayland developers subscribe to. They want Wayland to be display only, but that doesn't mean they would oppose an input protocol or a window protocol. They just don't want everything to be under the Wayland umbrella like systemd.

[mrighele]

> People who are thinking of a Wayland replacement at this stage, mostly because they don't like it, will waste their time reinventing the mature parts instead of thinking about how to solve the remaining problems.

Now, if only people deciding to replace X11 with Wayland heeded your suggestion...

[michaelmrose]

If they thought this then they misunderstood the people and problem space basically everything of importance.

[tasuki]

A very insightful comment. I was a victim to exactly the misunderstanding you explained (as are many other commenters here). Thank you!

[hulitu]

> Wayland developers assumed that the compositor developers will develop additional working groups

so, as Douglas Adams put it: someone elses problem.

[rjzzleep]

I use it as my daily driver. I used Sway for a very long time, tried Hyprland for a bit and am now running niri as my daily driver. Sway and niri are wlroots based, Hyprland at some point rolled its own because they didn't want to wait for wlroots protocol extensions. Sometimes I have to switch to Gnome to do screen sharing.

2026 and you will still run into plenty of issues with random behaviour, especially if you run anything based on wlroots. Wine apps will randomly have pointer location issues if you run multiple displays. Crashes, video sharing issues with random apps, 10 bit issues. Maybe in 2027 we'll finally make it. But I feel like these 20 years of development could have been better spent on something that doesn't end up with 4 or more implementations.

[myaccountonhn]

There also isn't nearly as much choice for wms. My favorite WM is cwm, but the closest alternative on Wayland is Hikari which is abandoned.

I noticed it's far far more work to build a wm for Wayland than it is for Xorg.

[rjzzleep]

Every single one of them has to fix the same set of bugs in different ways even if they share a wm library like wlroots. So unless you manage to get a critical mass on your wm, there is no way you can maintain it on your own. If I believed in conspiracy theories, I would have said that Redhat designed it to make sure they can control the ecosystem, but I think it's just over designed in all the wrong ways.

[abhinavk]

niri is based on smithay which is also used by COSMIC.

[rjzzleep]

I used rust for my sleep daemon, but personally I think rust is a suboptimal language for efficiently writing wayland code.

[mindcrash]

> The problems you have with one of them might not appear in another.

Because both have their own portal implementation/compositor with their own issues and service spec implementations. KDE has xdg-desktop-portal-kde, and GNOME has xdg-desktop-portal-gnome. On top of that each (still) has their own display server; KDE has KWin, and GNOME has Mutter.

> The reference compositor, Weston, is not really usable as a daily driver.

Weston is probably good for two things: Running things in Kiosk mode and showcasing how to build a compositor.

That's why you should at least use xdg-desktop-portal if you are not running KDE or GNOME. But this is a vanilla compositor (without implementations of any freedesktop desktop protocols), and as-is has no knowledge of things like screenshots or screensharing.

If you run any wlroots based compositor except Hyprland you should run xdg-desktop-portal-wlr which does implement the desktop protocols org.freedesktop.impl.portal.Screenshot and org.freedesktop.impl.portal.ScreenCast.

If you use Hyprland you should run its fork xdg-desktop-portal-hyprland instead which additionaly has things like file picking built in. Additionally you can/should run xdg-desktop-portal-gtk and/or xdg-desktop-portal-kde to respectively get GTK ("GNOME") and QT ("KDE") specific implementations for desktop protocols. And you absolutely should use xdg-desktop-portal-gtk instead of xdg-desktop-portal-gnome, because xdg-desktop-portal-gnome really doesn't like to share with others.

> With Wayland the each desktop is reinventing the wheel

Not really true, as I mentioned earlier there's still a DE specific display server running in the background (like Mutter and KWin-X11 for X11), and graphics in each compositor is driven directly by the graphics driver in the kernel (through KMS/DRM).

In fact, on paper and in theory, the architecture looks really good: https://wayland.freedesktop.org/architecture.html. However, in practice, some pretty big chunks of functionality on the protocol level is missing but the freedesktop contributors, and the GNOME and KDE teams will get there eventually.

[WhyNotHugo]

The fact that we need the entire xdg-desktop-portal stack for screen sharing on browsers is a major annoyance. We now have a standardised extension for screencasting and screencopy (formerly it was not standard, but had been around for years), but browsers only support the Flatpak stack, which has a lot of moving parts and IPC. Doing out-of-band IPC for this is kind of pointless when the client and the server already have a Wayland connection to begin with.

Outside of the domain of Firefox/Chromium, screencasting is much seamless. But 90% of the screen-sharing happens in browsers.

[thayne]

> Outside of the domain of Firefox/Chromium, screencasting is much seamless

Not always. In my experience Zoom screencasting is much, much worse than on browsers in Wayland. But that isn't terribly surprising given how generally bad Zoom UX is on Linux.

[tristan957]

What is the flatpak stack? Even unsandboxed apps use the portals.

[mindcrash]

> but browsers only support the Flatpak stack

Well, I think you should blame Google and Mozilla for that.

KDE (through Discover, https://apps.kde.org/discover/) and GNOME (through Software, https://apps.gnome.org/Software/) both have innate support for Flatpak.

So, given that the majority of normie Linux users will use Flatpak to install a browser, they will just use and support that in the browser (because the underlying DE wil more than likely have Flatpak support integrated too) and go on with their day to day.

Means that people who don't want to deal with Flatpak have to deal with Flatpak (or at least parts of it) too unfortunately.

[michaelmrose]

Most distros come with Firefox which most normies will simply use as is.

Also, software stores show both native and flatpak or on Ubuntu snap. One can easily install the system package of chrome if one doesn't want to deal with flatpak.

[thayne]

Technically, X is also just a protocol. But there was just one main implementation of the server (X.org), and just a couple implementations of the client library (xlib and xcb).

There isn't any technical reason we couldn't have a single standardized library, at the abstraction level of wlroots.

[gf000]

> all the quirks of the graphics drivers

This should ideally be solved at the kernel level - and I would argue it is solved there. Linux has the DRM abstraction for this very reason. Wayland actually builds on top of this abstraction, while Xorg was sitting in a strange position, not squarely in userspace.

[ezst]

Every major DE had its very own compositing implementation back in X11, so what was "easy" got to be more standardized, and what was hard remained so.