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

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

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

[abhinavk]

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

[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]

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.