I fear you are right. While there might be commits in the Wayland repos, featurewise progress has ceased. Waylands broken architecture has made progress hard to impossible. Porting of popular window managers is extremely slow since there is just no thought given to X compatibility. Input handling by each application on its own is insane and broken. Feature-consistency across compositors on things like screenshots is a pipe-dream. A promised easy ssh -X replacement doesn't work right after a decade.

Waylands broken architecture makes progress slow through unnecessary duplication, incompatibility and the lack of a smooth migration for many software packages (usually it's rewrite-time). Wayland should be abandoned and the design redone.

I also fear this. I dont care about most WMs being left behind, kde and gnome is already spread too thin. And I say that as a xfce user of ten years.

Got a new laptop with amdgpu and am enjoying the new life with wayland and gnome. It just took waay too long.

In what way is Wayland's architecture broken? Is there a critique floating around I could look at?

The design overview slides are their own critique: Wayland does almost nothing besides render buffer handling. Input? Applications job. Window decorations? Compositors job. Application talking to the Compositor? Somebody elses job. Clipboard? Maybe compositor or toolkit. Screenshots and remoting? Somebody elses job, but only after Wayland has bored the appropriate holes in its security model. This all leads to a ton of incompatibilities between compositors, toolkits and applications. And beyond Gnome, the full "featureset" is still not implemented, where "featureset" is barely adequate as an X11 replacement.

But the buffer handling is great, no more flickering...

> But the buffer handling is great,

... so long as you don't care about latency and don't mind a $3000 top of the line 64 core desktop feeling slightly slower than a machine from 20 years ago.

:(

This depends on the user. Personally I never minded the extra frame of latency.

And some of the newer Gnome desktops have even removed that, thanks to some tricky work by one guy, as I understand it.

I may have misunderstood the explanation but it seems to involve some nice timing getting all of the application buffers swapped just before the main GPU screen buffer swap. This gives applications long enough to draw updates, for the most part, and gets all updates into the next screen buffer update instead of the update after that.

Wayland has shipped on plenty of embedded devices with anemic arm socs as early as 2014

As I understand it the extra latency is relatively hardware independent, and caused by extra whole frames of delay from additional compositing layers. I expect an anaemic SOC to be slow, it's less fun when extremely high end machines are also slow.

Every time I pull a old system out of mothball and start it up I'm disappointed at how much less responsive the feel is of modern systems sitting right next to them.

This comment is mostly correct (as a daily Wayland user), with a few exceptions.

> Wayland does almost nothing besides render buffer handling. Input? Applications job.

Applications don't do more work to handle input on Wayland as opposed to e.g. X11. It's still event-based, and the compositor feeds input events to applications that can process them as normal. Keyboard, mouse and touch input are part of the core Wayland protocol, and tablet input is part of an extension that all major compositors fully support.

> Window decorations? Compositors job.

Kind of, it's the job of the application (client-side decorations) or compositor (server-side decorations). The compositor can choose which to use. CSDs give more custom look-and-feels to applications that have them (think Firefox or Chrome); SSDs provide consistent looks across all apps. GNOME only supports CSDs, but is an exception in that regard.

> Clipboard? Maybe compositor or toolkit.

Both: https://emersion.fr/blog/2020/wayland-clipboard-drag-and-dro...

Clipboards are (implementation-complexity-wise) scary in X11 as well.

I really hate to say it, but Canonical was and still is correct with starting Mir.

Canonical announced Mir out of nowhere in an attempt to gain control just like they are trying now with Snap. After the announcement of Mir their developers went to IRC and made abundantly clear they had no idea how Wayland works and that Mir was useless. Where is Mir now? Using Wayland.

People who were in the fence about supporting Wayland were now even more convinced they should ignore it. That's one of the reasons a decade later you still have this much FUD.

> Where is Mir now? Using Wayland.

It could have not gone that way. Now we've got two equally bad alternatives out there.

> That's one of the reasons a decade later you still have this much FUD.

I don't think you know what FUD means.

Nice ignore the part where they realized Mir was useless. They even went on an edit spree in their wiki page.

If Mir was so good and superior they would just keep developing it. Isn't that obvious? If the company who already spent all this dev time aka money on Mir doesn't believe in it, why would anybody else? They were even eating their own dog food and had some major industry pull at their disposal. The answer is they fucked it up.

> If Mir was so good and superior they would just keep developing it. Isn't that obvious? If the company who already spent all this dev time aka money on Mir doesn't believe in it, why would anybody else?

Not that I care or know a lot about Mir, but do you seriously believe that it was always the best technology that became successful and triumphed over its competitors?

> Nice ignore the part where they realized Mir was useless.

> If Mir was so good and superior they would just keep developing it. Isn't that obvious?

No, that's an arbitrary conclusion you've made. There are multiple reasons why a project might be killed, even if it's a good one. Canonical killed Ubuntu Touch but now it's gaining traction again because we have things like the Librem5 and PinePhone. Premature if you ask me but it makes sense as a business decision.

If we look across industry, would you say killing Google Reader was because it was inferior to others? I wouldn't.

the problem was that the "whole" open source community sponsored by RedHat, Intel etc... bashed the project to oblivion and left Canonical as the only contributor and put all the efforts on Wayland. This is just one of the reasons why Linux never reaches highs as a Desktop OS.

ChromeOS runs on Wayland, and it is used by WSL as well.

> ChromeOS runs on Wayland

Kind of. The Chrome browser itself doesn't run on Wayland, it runs on a custom compositor (I believe Aura?). Sommelier[1] is a Wayland compositor used for Linux apps on CrOS (Crostini), but Chrome doesn't use it. There is an ongoing effort (Lacros) to make the Chrome browser itself run under Wayland on CrOS, but it's not public outside of development builds (and not yet on par with the "native" version).

[1]: https://chromium.googlesource.com/chromiumos/platform2/+/HEA...

What's the alternative then?

Lack of an alternative does not make Wayland any better unfortunately.

So what do my Linux machines run desktop sessions on?

webvnc

-- whatwg

Windows?

> This should hardly be surprising but a prominent Intel open-source developer has conceded that the X.Org Server is pretty much "abandonware" with Wayland being the future.

Why do you say Wayland is abandonware? The last activity in the repo is from a week ago https://gitlab.freedesktop.org/wayland

> The last activity in the repo is from a week ago

Actually most of repos you linked have the last activity of months ago. It's pretty worrying though.

Wayland is just a protocol. Look at the work on actual compositors, like mutter and wlroots to see some activity https://github.com/GNOME/mutter https://github.com/swaywm/wlroots