Further thoughts on Wayland

Previously on The Cat Fox Life, I wrote an accidentally now-infamous article on what I felt were lies/misconceptions that Wayland users were spreading about the Wayland system.

One of the Wayland community’s more prolific developers wrote a rebuttal to my article, then directly responded to me on HN. I hadn’t yet gotten around to properly responding to this in earnest, because I had a lot of personal IRL drama to deal with in February. I’m feeling a little under the weather today, with a minor head cold and sore throat, but Drew has reached out to me personally and the time to write this is now.

Before I begin, I feel like the original introduction to my previous article may have been worded slightly incorrectly. This was never an indictment of the developers of Wayland, but rather the rabid fanboys who spread BS on Reddit, forums, IRC, and such. There are rabid fanboys of systems I actually like, too; musl, s6, KDE, and Firefox come to mind. I don’t like those fanboys either, and I could probably write articles about lies they come up with, too. (Welcome to the Internet, I suppose.)

Drew wrote: LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory.

That’s perfectly correct, and I noted in my previous article: “I’ve been told that mentioning something that uses LD_PRELOAD is cheating and that you could own any application, not just Wayland. That is true! But this is being sold as “impossible to keylog”. It isn’t.”. This isn’t a mark against Wayland, but again, a mark against dumb people saying things they shouldn’t be and generating buzz. There have been multiple people on IRC and Reddit that have said that Wayland is immune to keylogging without clarifying that it’s the protocol, not the implementation. The developers of Wayland know that you need to secure the whole system, but these fanboys don’t.

Drew wrote: many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard.

I said in my article: “Wayland compositors universally require OpenGL profiles that older hardware, less expensive hardware, libre hardware, and most embedded chipsets do not provide.” GLESv2 is still not going to work on framebuffers, libre FPGAs, or embedded chipsets. At least, not without LLVMPipe, which would use a lot of CPU time and power on the hardware where it’d be relevant. That said, Drew wrote in his response: “writing an fbdev backend is totally possible and I’d merge it in wlroots if someone put in the time.” This gives me hope that perhaps it may be possible to run Wayland compositors on framebuffers some day. Additionally, I was too harsh when I said that Wayland is “designed” to “require” blobs. Of course it isn’t, and I shouldn’t have said that.

I would also like to note that although wlroots is used by “over 75% of all compositors”, there are four main compositors that I would suggest people think of when they think of Wayland: KWin (KDE Plasma), Mutter (GNOME, replacing Metacity), Sway, and Enlightenment. As far as I know, wlroots is only used by Sway out of these four. So while it has high number of market share, I’m not sure it has the same high number of installed user base, which coloured my initial perception on compositor GPU requirements. I am not sure what Mutter requires out of GPUs, but KWin’s Wayland compositor requires more than base GLESv2, and far more than KWin’s X11 compositor, which supports XRender (software) and OpenGL 2.0. Similarly, in my experience Enlightenment runs much better on older hardware using X11 rather than Wayland. It is good to know, though, that not all Wayland developers feel that they should be overutilising GPUs so much. I am glad that if wlroots had to require OpenGL, GLESv2 is the standard they chose.

Drew wrote: For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work.

This was actually very nice to hear! Wayland developers seem to want network transparency, but just don’t have the interested parties right now to make it reality. It’s good to know that ideas are not rejected in Wayland like the Wayland proponents in /r/linux said they would be because “that’s legacy X11 garbage”. (I suppose this comes down, again, to fanboys yelling and screeching.)

Drew wrote: A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation.

The difference being I rarely hit driver bugs or Xorg server bugs, but regularly hit compositor bugs. (KWin has crashed 27 times in the past year. Xorg, once, due to – you guessed it – a radeon.ko bug.)

Yes, the security holes are blatant speculation and were phrased in a mean and combative way. It was wrong and I publicly apologise, not only to Drew and other Wayland developers, but to any that may have felt personally attacked. Of course I didn’t mean it to be a personal attack, but it came off that way due to being written poorly. I regret that, and hope to learn from this experience.

As a conclusion, I still personally don’t see myself running Wayland any time soon. However, I would be happy and willing to merge Wayland packages in to Adélie Linux if someone is willing to maintain them.

5 thoughts on “Further thoughts on Wayland”

  1. While I appreciate that Wayland isn’t all bad – I very much agree with some of the points in your original article. The biggest is that compositors are not all equal, and therefore KWin runs horribly for me, however Mutter seems to run fine.

    There are a couple of other issues:

    1. Wayland developers such as Drew (not sure if he works on wayland itself, but he is influential in wlroots, and hence as he says 75% of wayland based compositors) are zealots who write rants about how ‘NVIDIA Sucks’ and ‘Buy hardware that runs your software’ – which is a major blocking point to me ever using Wayland because developers have this regressive attitude to supporting hardware that a large portion of the community uses. So developers complain about political issues instead of actually implementing software that works and everyone I know still uses Xorg because Wayland isn’t ready. These sorts of politics have plagued Wayland for years.

    2. While Xwayland is a cool idea, why are we making a compatibility layer for a new display server instead of just updating the old display server. I appreciate that Xorg has grown more and more complex, but it does it’s job and almost every piece of GUI open source software depends on it to run. (e.g. I switch to Gnome on Wayland, and MPV breaks, I have to add some experimental configurations, and it runs terribly – switch back to gnome on xorg and everything is fine.)

    3. Wayland causes some issues it was supposed to fix – I see many comments about ‘screen tearing’ and never see any while running xorg – I run wayland, and I can see them almost instantly. Xorg has a more prescribed way of doing things, which results in a more consistent output – bringing us back to ‘all compositors are not equal’

    Liked by 1 person

    1. The funny thing is, talking to other Wayland developers, I’ve found that a lot of them haven’t even heard our voices. It’s almost like they’ve been insulated by the Drews of the world. One in particular had never even thought about making a way to swap compositors at runtime, and thinks it’s an idea worth looking in to further. So perhaps Wayland might eventually get to where X11 is now, though I do agree that I don’t see why we can’t just update X11.


      1. ‘We’ can’t update X11 because it is more fun to start a new project from scratch than to fix old code. There really is no need for wayland at all.


    2. 1. Nvidia should support Wayland. Having several kinds of drivers and APIs defeats the purpose of an operating system. Nvidia provides a Linux driver. It’s their job to make it work the Linux way. Software shouldn’t need to do this:

      if (card.manufacturer == Brand_A) then run_code_A()
      else if (card.manufacturer == Brand_B) then run_code_B()
      else if (card.manufacturer == Brand_C) then run_code_C()

      Do you care about the brand of the mouse and keyboard that people will use when you write a program? No. If you had to, then it would be a terrible design. Wayland shouldn’t have to care about that too. It should just use Linux like it’s supposed to be used.

      2. Updating Xorg won’t fix its issues. Unless you change the X protocol and rewrite everything from scratch. That’s being done, and it’s called Wayland.

      3. The current implementations are causing those issues. Give it time. If people don’t give a chance to softwares because they start with lots of flaws, then no software will ever have a chance.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: