Hacker News Reader

Comment by londons_explore | Hacker News Reader

Every 6 months I try switching to Wayland. I spend an hour or so using it for regular desktop gnome use and fixing minor bugs (ie. The kind I can fix with a config tweak). I then switch back again because it just isn't there yet.

Recent issues:

* The brightness control for my screen doesn't work with it.

* The mouse sometimes lags

* Graphical corruption in Chromium when on webgl sites.

* Blank screen after resume from hibernate.

* Seems to randomly freeze forever sometimes after an OOM killer run.

* Chromecast wouldn't work

View on HN

I'm beating a dead horse at this point, but there's no such thing as "switching to Wayland".

What most people mean when they "switch to Wayland" is that they're switching from Gnome on X11 to a "pure Gnome" stack that uses Wayland and a bunch of other Freedesktop standards for interopability. There is absolutely no code from the "Wayland project" running there, because the Wayland implementation is Gnome's own (it's called Mutter). Similarly, KDE's implementation is in KWin itself. The source article is from an author of yet another window manager (Sway) implementing Wayland.

What you're observing is not "Wayland not being there yet", it's Gnome not being there yet. All of these deficiencies have nothing to do with Wayland itself: they're general QA issues that plague an underfunded Linux desktop that's making a slow technology transition.

I completely agree. But as a user the distinction doesn't matter.

Maybe, but I think it matters when discussing it. If we talk about it like this, it seems that Wayland is to blame. But there's nothing wrong with Wayland [1].

Wayland here ends up often being the scapegoat of a Linux community that looks to want to change but can't sort itself out. The result of blaming these issues on Wayland instead of - mostly - Gnome and KDE means that we're not going to the right places to have this fixed. In terms of bug reports, and contributions of code and money.

[1]: I mean, if you can come to terms with the substantial architectural differences implied by Wayland w.r.t. to X11. But that's a discussion on another level.

The distinction really really does matter, if your argument is "wayland is shit".

That depends on if the precise argument is closer to "Wayland, as experienced by everyday users, is shit" or "Wayland, as a Platonic ideal, is shit."

People, especially people trying to work done on their computers, usually mean the former.

Just say Mutter or Kwin are shit then. Saying Wayland is shit is like HTML is shit because you don't like Firefox.

Most users don't know the difference, to either of those statements. For them "the internet is broken".

I don’t disagree but in a forum of tech-savvy people I expect some level of preciseness. We shouldn’t be saying Wayland sucks when we’re talking about Mutter in the same way we shouldn’t say the internet crashed when we mean Chrome crashed.

Unknowing users can freely associate Wayland with bad vibes due to how KDE and GNOME chose to brand their new compositors but we can do better.

Nobody complains about the W3C because their internet is broken.

That doesn't work for users though. I've used KDE since the 20th century and it has been pretty reliable. Kwin hasn't been shit. Maybe it's best to say Kwin + Wayland is shit, or Mutter + Wayland is shit.

But if Kwin & Mutter aren't quite shit when it was combined with X, but are shit when combined with Wayland, how does that shape perceptions of Wayland?

“Kwin the X11 window manager” and “Kwin the Wayland compositor” are entirely different things that look similar on the surface.

In an alternative universe there would be Kwin the X11 display server which would replace Xorg. I’m sure it would just be as big riddled and feature incomplete in the early years of its development.

HTML was complete *it until CSS, flex box, grid, web components, etc. are invented, so users are escaped to Flash, ActiveX, and Java applets.

It still smells, because I cannot load my own web components library or/and my own CSS for use on all sites, so every site MUST reinvent wheel.

When Firefox for Linux used native GTK+ UI elements in web pages, with user theme applied, every web page looked like native applications. It was excellent. Then this feature was cut, because "every page must have the same look on every device/OS combination". F><k. Now every web application tries to reimplement the look of Gnome 2.x, and does it poorly.

If every browser was shit, people would say HTML is shit.

Precisely this.

There's a meta-lesson useful here for anyone who doesn't know it yet: modern software has network effects. And the same phenomena you see with other networks apply to software stacks. If everyone else has implemented a protocol wrong, for example, and your software comes along that has implemented the protocol correctly, but as a result your software doesn't work with the existing stack,

a) Odds are, the rest of the world will not change to work with your software

b) New users, using your software, will perceive the problem is your software doesn't work, not that the rest of the stack is wrong and you're the only one that did it right.

Maddening, but it's the nature of complicated systems built by thousands of people in a distributed fashion.

(I can't lay hands on the link right now, but there was an ex-Microsoft engineer who had a blog where he talked about the heroics MS developers would go to every major Windows release making sure their OS was compatible with popular user software. It didn't matter that they were the company setting the rules in their ecosystem... If the latest version of Windows broke Photoshop, they had to figure out why. In that particular instance, it was because Photoshop had gained some performance optimizations by baking binary images of default structs the OS gave it into their code instead of calling the right API to get a struct properly initialized, saving a library call. MS had to reimplement some C++ structures in C so they could maintain the memory image of the relevant structs to avoid breaking Photoshop).

Why does this distinction matter? Gnome on X works perfectly fine, Gnome on Wayland does not. Why does it matter it to state that Wayland is a protocol, not the implementation?

Because if what's bothering you is the implementation and not the protocol, you should be talking about fixing the implementation instead of diverting attention to the protocol? I might not understand your question here.

If every implementation of a protocol seems stuck with deal-breaking bugs or incompatibilities, it's time to start asking whether the protocol itself has some problems that make it impossible to implement consistently - unstated assumptions, for example, in the reference implementation that never made it to the protocol spec.

For a modern example of this in action, see Bluetooth and the madhouse of device 'quirks' you have to settle with day-to-day, since each device has subtly protocol-breaking opinions on how to implement it.

I would agree here, if you could make a reasonable case that the problems trace back the protocol. But my point here is that practically all issues at hand happen outside of what Wayland is used for.

Wayland is a display protocol. Practically all of the pain people are experiencing has nothing to do with how Gnome/KDE/Sway really display things differently. The pain everybody experiences is that the realization that suddenly we need a new input stack too, a new way to screenshare, a new way to do clipboard access, a new way to do a bunch of other things. All stuff that also needs to made, standardized, and achieve maturity outside of the new display protocol.

It's tempting to call that fallout of other stuff that needs to be changed "Wayland" as well, but I'd say that misses the point completely and calling it that won't help anyone get this stuff fixed.

So there's a terminology conflation issue, then: people attacking Wayland proper for issues that are actually about the 'Wayland ecosystem'. I could see that generating increasing problems if there is no observable gameplan for or encouragement to develop those pieces people have come to expect of a full desktop stack.

Mind that I have no formed opinion of Wayland myself, having not used it. Trying to deduce probable causes from hearing people duke it out here and elsewhere.

I would say that's a fair summary.

On Linux, there's X11 based desktops and "post-X11" desktops. "Post-X11" would involve implementations of Wayland and Freedesktop Portals [1], using libinput [2] - and some other things I'm forgetting. All these things don't depend on Wayland and run fine on X11 too (heck you can even run a Wayland compositor in an X11 window), but most of this stuff is pretty new, implementations have lots of QA issues, and application adoption is also not fantastic. On X11 you can just talk to the X11 socket directly for what you want as a workaround, but on post-X11 you have to adopt a new means of doing it. And that hurts.

[1]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

[2]: https://www.freedesktop.org/wiki/Software/libinput/

It's funny that in the case of systemd both the scenario and hence also the complaints were the complete opposite. Namely that systemd does everything, that in an idealistic world should have been decoupled from the core. (Which was also FUD since the internals actually are decoupled and work alone).

It is like blaming HTTP because of the cookie warnings you get everywhere. Yes, cookies are part of HTTP, but the warnings are not.

Gnome on Wayland works pretty great for me. (No issues with brightness etc). Occasionally I log into an X11 session because Wayland screen sharing doesn't work that great.

Because Gnome on Wayland might not work, but maybe KDE on Wayland does or "i3 on Wayland" aka sway does. That's like saying "I tried switching to Linux but it doesn't work" because you couldn't make the dropbox client run. The protocol (linux ABI) works, but the implementation (dropbox on linux) doesn't.

That's funny, because for me, it's exactly the opposite. I use Gnome on Wayland/Mutter and it works great - I've never had a linux desktop that had such great UI rendering. Gnome on X doesn't work and is buggy - it's riddled with graphical glitches that other platforms (even smartphones and tablets) don't suffer from. How can that be considered to "work"?

But my requirements are different from yours.

> it's riddled with graphical glitches that other platforms (even smartphones and tablets) don't suffer from. How can that be considered to "work"?

If you've been shooting yourself in the foot all your life, eventually you'll stop noticing that your foot is bleeding.

Both of you could be right, depending on the hardware sometimes GNOME w/ Xorg works better and sometimes it's the other way around.

That would be pretty amazing if Xorg ever rendered in a way that was even equal to other platforms (mutter, Windows, android, MacOS, ...) given how crazy the separation of concerns in X is and how many silly boundary crossings need to be made to process events and render them.

It would have to rely on compositor and driver bugs in those other platforms.

This is be a fine distinction to make if there is an implementation of Wayland that is there. Then we can say this is just about a particular implementation, and not Wayland itself.

If no implementation of Wayland is ‘there’, it seems pretty reasonable to say Wayland is not there yet.

People use the name "Wayland" as an umbrella term for "the entire effort on the Linux desktop get rid of X11". I'd generally agree that there aren't any desktops that flawlessly replace X11 [1], but I don't like that Wayland is the name for "the entire effort on the Linux desktop get rid of X11".

I think it can be seen in OP's list that most of the issues that OP raised are actually not due to deficiencies in the display protocol. Specifically replacing of the X11 display protocol with the Wayland display protocol. But Wayland solves fewer problems than X11. So to replace things like standardized screen recording and input processing, you need other things on top of Wayland.

And that's where by far the most issues with "Wayland" come from - stuff that has nothing to do with the display protocol, but the tremendous pains it takes to replace X11.

[1]: It's worth pointing out for fairness that X11 based desktops are also pretty flawed even if you're used to some of the flaws.

I mean this is all true, but it’s worth pointing out that Wayland is actually an effort to get rid of X11 on the Linux desktop by introducing a new protocol.

Given this, it’s not surprising Wayland has become the name associated with the overall goal.

It is actually one of the big, unfixable, conceptual problems of Wayland that all the effort is duplicated in each compositor. The Wayland concept pushes out most of the work to the DEs. That of course will result in tons of predictable inconsistency, incompatibility, bugs, delays, consolidations and general pain. Wayland devs are then generally in the lazy "worksforme, use sway (or whatever)" position while the user (of some other compositor) will be out there complaining to yet another maintainer duplicating yet another feature badly. Lather, rinse, repeat.

Wayland is bad design, and it shows in the users' and maintainers' attrition.

But isn't this the point of wlroots?

I honestly think this complaint is completely bogus.

This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.

The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !

The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.

[1]: https://github.com/swaywm/wlroots

Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places).

What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.

Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.

No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.

The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.

At least between-app DPI inconsistency was not a thing before this. Now its a thing, added to the stack of configuration problems.

If you support multiple DPIs then that will always be an issue, regardless of what display server you're using.

Not if the protocol allows the exchange of desired DPI/scaling.

Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus.

The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.

Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling"

edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1

[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

> It is actually one of the big, unfixable, conceptual problems of Wayland

Why not have a shared implementation?

Because then you end up with something like X11, which we already have.

The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11."

Personally I think something like that is an inevitability.

> which we already have.

It'd still solve a lot of issues that X can't.

Because the Xorg mono-culture was bad. There was no ability to write other X11 display servers from the spec alone. You either did what Xorg did bug for bug or apps broke. By having many different implementations all speaking a common protocol you make it harder to calcify the behaviors of any one implementation and ensure that the spec is what apps code against.

People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.

That's fine, I know. But acting like Wayland is feature complete when it obviously isn't is pretty ridiculous. Instead of solving hard problems the Wayland maintainers are acting like you're stupid to want to have the features solving the hard problems enables.

I think Wayland is about as feature complete as it's gonna get at this point. Mutter, Kwin are still working on adding features to support workflows that relied on the loosey-goosey nature of Xorg. Like Xorg never had "support" for global hotkeys or screen sharing. It's just that programs were allowed access to all inputs and the screen buffer. Designing a system where only some programs are allowed to do that isn't trivial.

That's more or less why I sometimes log in under X instead of Wayland - I can't run Fontforge under Wayland (not sure why and I don't have the bandwidth do dig deeper). Luckily, the machine behaves the same way.

I don't understand why it's so important to have multiple broken implementations before having 1 working implementation. Especially in open source where there's no monopoly risk.

Diversity is great but equality in failure is not helpful.

> Because then you end up with something like X11, which we already have.

X11 is a protocol. What you mean is that we end up with something like Xorg, an implementation of X11. Which is still incorrect because a major design goal of Wayland is to move as much logic as possible from the server to the client.

> a major design goal of Wayland is to move as much logic as possible from the server to the client.

I wonder how long it'll take to have a Wayland server running on the AT&T Blit...

We do, wlroots. But it came _after_ mutter, and maybe even kwin, so right now there are basically three.

Wayland isn't bad design, at least not in the way you're describing it. I feel like there's some confusion about what Wayland actually is. It's a document that describes how surfaces ("windows") should talk to a compositor ("display sever"). That's it. In a parallel universe Kwin and Mutter would be X11 display servers and we would have all the same issues. Nothing is stopping the existence of a single extensible compositor to rule them all and be the base on which every DE/WM is based but it hasn't happened yet.

When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.

This is absolutely right, and wlroots is not a fix once you already have 2 implementations

Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.

You're dancing around the problem: Wayland works (such as it is) by offloading functionality that was part of X to the desktop software like gnome or kde and then saying "but that's not our problem!" when something breaks. Never mind that program collection 'A' (including X11) was working and program colleciton 'B' (the Wayland way) wasn't.

That's just it, Xorg did tons of things that it never should have been involved with. It used to have a print server FFS.

Wayland is trying to do one thing well, whereas Xorg did many things poorly. It's valid to feel frustration that the community doesn't coordinate to put those APIs in place, but it's very much not valid to blame Wayland developers for it.

> You're dancing around the problem

Please be a little bit more charitable: I'm very candid about the usability problems on the Linux desktop, I'm just telling people where they need to send their time, money and concerns to fix it.

> "but that's not our problem!" when something breaks.

Which is the entire point of getting rid of X11. Wayland is a display protocol and does not intend to solve all of the problems that X11 ended up solving, same as the display stack in any OS designed after 1990 (like Windows, Mac OS X, BeOS, Android and ChromeOS) do not solve these problems either.

On the face of it that does sound even worse.. Instead of just having to fix those issues once you will now have to fix them in every desktop environment/window manager equivalent?

>> What you're observing is not "Wayland not being there yet", it's Gnome not being there yet. All of these deficiencies have nothing to do with Wayland itself.

While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.

My biggest issue with gnome is that it doesnt remember where my windows were last time I ran an app. Someone over in way-land probably should have told them that would become a their-problem so it could be addressed it sooner. Same with window decorations, they should be handled by the compositor IMHO. Sometimes a new thing should come with recommendations for use.

> While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.

Deflection is entirely my point here :) These things are real problems, but they should be fixed in Gnome/KDE/Sway/wherever you find them. Complaints should be addressed there, and not at "Wayland", because "Wayland" can't fix em!

Agreed, but my point was they could have made more clear how the line was moving relative to what they were used to. Maybe they did and it's just an issue of resources.

When I'm at my framebuffer terminal, I can either type 'startx' or 'sway'. If I go from typing 'startx' to typing 'sway' does that count as "switching to Wayland"?

Since the startx command starts the X11 client and server maintained more or less straight from the X.org project, and the sway command does not start any code that came from the Wayland project, I'd say that counts as "switching to Sway".

Wayland is the implementation detail in Sway to have a display protocol your Gtk, Qt and XWayland apps use to draw themselves, really no need to draw more attention to it than necessary. It's the Sway implementation that does all the magic.

Yeah Sway looks really appealing to me since i'm already using i3wm. But every now and then i'm searching if screen sharing on MS Teams already works. As a Software Engineer in this pandemic i rely a lot on screen sharing. But every time i search for it i find out that it still does not work (without a work around). That's basically the only thing that holds me back. Does anyone know if Sway or Wayland is trying to fix this? Seems like a high priority fix to me in this pandemic.

xdg-desktop-portal-wlr works (with a bit of cli work) with MS Teams in chromium with a flag to enable pipewire. The Desktop app will only support it when the Electron release containing pipewire support releases & gets used in Teams.

> ...or as I've recently taken to calling it, Gnome plus Wayland

gnu wayland thank you very much.

"3 incomplete implementations and 0 complete implementations." Is Desktop Linux's epitaph.

really?!? what next? tomatoes are fruit?

asshole.

Happy user of Sway for almost a year already(https://github.com/rvolosatovs/infrastructure/commit/b765860...). Some of the issues you mention I have experienced on X11, but they were fixed once I switched to Wayland. One of the most notable changes for me was hotplug - I struggled with it on X for many years, now it just works by default and I didn't even need to script anything(https://github.com/rvolosatovs/infrastructure/blob/0e17a1421... and I even wrote my own tool to handle this, because the X11 ecosystem is full of crap https://github.com/rvolosatovs/gorandr).

Overall, my Linux GUI experience has never been as smooth as it is now on Wayland and I tried pretty much all common DEs/WMs in last 8 years.

X11 is not even remotely close to being "there" compared to Wayland and if Gnome implementation sucks, then please first try better implementations first before writing comments like this.

No, Wayland protocol is not perfect and yes, some niche use cases are still not covered, which is why various extensions of the protocol are still being developed. X11 at it's current state is nothing but a collection of hacks glued together. Wayland is, however, a very robust, secure and well-designed modern protocol, which, most importantly and contrary to X11, actually works.

Anecdotal after using Wayland for the last few months:

  * The brightness control for my screen doesn't work with it.

Never been an issue on my Samsung laptop. I strongly suspect this depends on your hardware, but I'm not going to spend a week to prove it.

  * The mouse sometimes lags

Never happened outside of catastrophic load scenarios.

  * Graphical corruption in Chromium when on webgl sites.

Are you using Nvidia? I've had no major graphics glitches since using AMD.

  * Blank screen after resume from hibernate.

Never happened.

The last two aren't applicable, since if anything has been OOM killed recently I didn't notice, and I don't have a Chromecast.

> Graphical corruption in Chromium when on webgl sites.

Can’t speak to Chromium or Wayland, but Chrome on Mac has this problem for me and I just had to completely disable hardware acceleration.

Did you report any of these?

They all come up with plenty of Google results when you search for them, so I assume the devs are well aware but have other things on their plate to work on.

Reply on news.ycombinator.com