A response to the "Boycott Wayland" article

Link to article: gist.github.com/…/9feb7c20257af5dd915e3a9f2d1f227…

This OUTDATED article gets posted all the time. The full story is the guy is a massive FreeBSD fan so he is trying to convince more people to keep on using Xorg because he wants to make sure it isn’t abandoned. Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries.

Let’s go through the article point by point:

Wayland is broken by design:
  • A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.
  • You cannot do a lot of things: What, like allowing Windows to see your keystrokes, which makes developing a keylogger absolutely trivial?
  • There is not /usr/bin/wayland: Yes, because Wayland is a set of protocols, which a bunch of projects can implement as few or as many of, as they see fit, thus avoiding the issue of “unmaintainable mess” that has plagued Xorg for years.
  • It offloads work to the window manager: Again, yes, that’s a part of its structure: do the protocols, then let the compositor implement them. That way, you have multiple implementations running simultaneously that are well integrated with their window managers and thus more efficient and performant. It also means that when a compositor suffers from too much cruft, we can just make a new one, while application developers wouldn’t really have anything to change because if their application works on Wayland, then it works on different compositors (unless it is made specifically for GNOME, or specifically for wlroots, like wlr-randr)

…so what works on DE 1, doesn’t necessarily work on DE 2: True, because oftentimes, it doesn’t need to. Not implementing features can lead to a more lean and streamlined software solution. However, sometimes features are necessary and only implemented in some compositors. This usually happens because the universal solution is not ready. KDE are often known to do this with Plasma and KWin.

  • Wayland breaks screen recording applications: Correction: The following screen recording applications were not built to support Wayland (because Wayland is new to them or they just decided not to, or they were either too busy or too irresponsible enough to realise Wayland is coming, and has been for over 10 years. In defence of the devs, they probably wanted to make sure Wayland will become stable enough, but it has been the default even on Debian for many years now, so…

In terms of the applications, I’m not aware of many of them, and for this sort of application, I’m sire alot of work is required to change the graphical backend, so I understood that some smaller projects gave up, but OBS has been working on Wayland for quite a while. Is it perfect? I don’t think so, but back when Brodie Robertson was using Hyprland, he was recording his videos using OBS. This article is quite outdated.

  • Wayland breaks screen sharing applications:

As the update shows, Jitsi now does work on Wayland.

Zoom only seemed to work on gnome, BUT if you open up the Link to the zoom issue and read through the comments, there is clearly a person that clearly states that they changed /etc/os-release from PureOS to debian and it worked for them, all because of some pointless limitations enforced by the Zoom developers. As the person posting the issue states “Currently, the zoom application has put an arbirtrary restriction on screensharing so it ONLY works on GNOME, when the api being used works on all wayland desktops.” Read that again. It’s a pointless restriction put there by the Zoom team because they couldn’t be bothered to test anything non-GNOME.

And the last issue is a problem with the article writer’s own appimage. I don’t know about that one.

  • Wayland breaks automation software

As stated IN YOUR FACE, it is an application that works on X11 only. Yes, Wayland is not made to use such applications, but it doesn’t mean they can’t exist. Every heard of ydotool (remember that name)? Now you have.

Next up, we have 3 issues about GNOME and KDE global menus (1 for GNOME, 2 for KDE). From the little I know about global menus and using these projects, as well as considering that they are both incredibly stable on Wayland and Fedora KDE will be dropping Xorg completely, I think it’s safe to assume these issues have probably been fixed. Please correct me if I’m wrong.

  • Wayland breaks AppImages that don’t ship a special QT plugin: Great! Just ship the plugins then! Problem solved! Also, quote from the article: “However, there is a workaround: “AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode” (see below).”
  • Wayland breaks Redshift: Once again, a program built for Xorg doesn’t always work on Wayland. Especially if it works with the compositor, like a colour temperature control application, or a wallpaper setter. The article quotes that “Redshift does not support Wayland since it offers no way to adjust the color temperature” which is not true, as proven by Redshift alternatives like Gammastep.
  • Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure, but Hyprland has not allowed that to stop them from implementing a solution where you can choose keys that will be passed on to the application. Boom, problem solved. Unfortunately, it doesn’t seem to be implemented anywhere else, as far as I know.
  • Wayland does not work for XFCE: Come back to me in late 2024 after XFCE 4.20, which will introduce Wayland support, has been released. Also, wiki.xfce.org/releng/wayland_roadmap
  • Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.
  • Wayland does not work properly on Intel hardware: Again, I’m using AMD, so I can’t confirm or deny this, but considering the Intel drivers are open source, and I’ve heard about many, many improvements made on the Intel side of things, I think it would be reasonable to assume it has been fixed.

Edit: As multiple Intel users have pointed out in the comments, there seem to be no issues on Wayland with Intel hardware.

  • Wayland prevents GUI applications from running as root: This one has been crossed out as the article writer admits there is a solution
  • Wayland is biased towards Linux and breaks BSD: Arguments seem valid, and I’m guessing, are correct. This one is likely true and will remain so for the foreseeable future.

Edit: And yet, it seems that there are Wayland compositors for FreeBSD, so the above might only be true for OpenBSD and others.

  • Wayland complicates server side decorations: From what I’ve heard, this is true, mainly something to do with some GNOME agenda, as the article states. I think that one is true.
  • Wayland breaks windows raising/activating themselves: The linked issue is closed and seems to be resolved. There is a mention of a WIP protocol at the time (2019) that woukd fix this. I had difficulty following the discussion, but I think this has been fixed.
  • Wayland breaks RescueTime: Because RescueTime depends on X11-only tools like xprop.
  • Wayland breaks window manager: What you’re describing is Wayland breaking X11-only tools for doing various tasks in a window manager. They are X11 tools, so of course they don’t work on Wayland. I’m not sure if there are alternatives, but I’d guess there probably are. I know for a fact that Xrandr has alternatives like wlr-randr and kanshi for wlroots.
  • Wayland requires {instert WM here} to implement Xorg-like functionality:Yes, it does.

Quote from article: "As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. "

DEs: GNOME, KDE, MATE, XFCE, Cinnamon, Budgie, Enlightenment, and recently even Pantheon have either announced to start work on, have started work on, or already support Wayland.

Window managers: Qtile is doing it. Xmonad wants to hire a dev to do it. Dwm has a spiritual successor called dwl. i3 has a drop-in replacement called sway. Openbox has 2 spiritual successors called labwc and waybox. Now you might notice one of the biggest WMs is missing on here: AwesomeWM, which is such a shame. The Awesome devs have said they would be okay with someone taking on that challenge (which has already been attempted, as evidenced by the existence of way-cooler), but it seems that they wouldn’t do it themselves.

As for the projects mentioned in the article, (JWM, TWM, XDM, IceWM) they are too small and obscure, and will likely fade away with Xorg.

  • Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol I don’t know about that one, ao I’ll assume it is still the case. Edit: Ignoring the fact that the link is broken, it basically just links to a docs change where skipTaskbar is marked as unsupported on Linux. Link: github.com/electron/electron/pull/33226
  • Wayland breaks NoMachine NX The link points to a page that has this marked as “SOLVED, Released in version 8” so I’m guessing it has been solved.
  • Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

Edit: As pointed out by some people in the comments, there are also alternatives to xclip like wl-clipboard.

  • Wayland breaks SUDO_ASKPASS: That link seems to point to the way this issue has been resolved so I don’t see your point.
  • Wayland breaks X11 atoms: I lack knowledge on the topic so will assume this to be a valid argument
  • Wayland break games: I’m 99% sure you can disable Vsync??? But I’m not a gamer. Also, WINE on Wayland is getting better and better. Soon enough, I hope the subpar performance will become better performance (when compared to Xorg)
  • Wayland breaks xdotool: Well, yes. There is ydotool, but you’re looking for a 1-to-1 replacement and I’m not sure if ydotool fits the bill for that.
  • Wayland breaks xkill: Well, yes. Again. It is an X application, so of course it does. Though for some reason I remember it working once on wayland. Must have been an xwayland app, or maybe I’m just misremembering this.
  • Wayland breaks screensavers: Yeah, that seems to be the case.
  • Wayland breaks setting the window position: That is a WIP for Plasma, not sure about any other projects, so assume true for anything else.
  • Wayland breaks color management: Not anymore. That is being actively worked on.
  • Wayland breaks DRM leasing: While not rhat familiar with the issue, my understanding of the topic is the article is correct: not all compositors support it.
  • Wayland breaks in-home streaming: Not familiar with this, so will assume true.
  • Wayland breaks NetWM/EWMH: Yeah, that seems to be the case.
  • Wayland breaks window icons: Yeah, that seems to be the case, as said in the article, when no .desktop files are used.

And that concludes my response to this article based on my fairly limited knowledge on the topic. If I got anything wrong, please, please let me know. As you can see my knowledge is quite limited, and as such, any corrections (preferably backed up with evidence) would be appreciated

legend_sandworm,

My main issue with Wayland is the fragmentation. Abstract protocol which could be implemented by particular DE/WM means nothing to a user which now doesn’t have a guarantee that their tools will work under all environments. For example, some screengrab utility could work under Gnome, but will not work under wl-roots based WM just because the relevant protocol is not supported there. That’s a major drawback to me, we lose flexibility and kinda forced to use mainstream DEs where they have enough devcapacity to support most of the features from Wayland protocols. Contrary to X.Org where most of the functionality is implemented by server itself and protocol exposed to the clients is way simpler.

superminerJG,

From a developer’s standpoint, one of the bigger pain points of Wayland is window embedding.

If you want to embed from an external process, the only way to do this is to have your application expose its own Wayland compositor and then have the embedded process use that Wayland compositor. No one has made a library for this as of yet.

If you want to embed from the same process, it shouldn’t be too difficult; you just need a wl_subsurface. However, this doesn’t work too well with most GUI toolkits.

Wayland is just radically different from every other windowing API, and I’m hoping that the GUI toolkits can adapt.

Metatronz,

I just got one question. What is cruft?

LeFantome,

Old and useless stuff that builds up over time

NoLifeGaming,

Although I don’t currently use Wayland I’m excited and look forward to its continued development.

art,
@art@lemmy.world avatar

Boycott Wayland. It breaks everything!

Other should stop just using it because it doesn’t work for you? Wouldn’t it make more sense that those who do work on it keep improving it so it doesn’t break?

vildis,

Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.

Posting this from Hyprland on NVIDIA, arch (btw) and the nvidia-open-dkms driver, but yes, NVIDIA isn’t fully there yet.

Akinzekeel,

I keep reading this all the time but I have the same setup and I don’t understand what’s supposedly wrong or broken with it. It just seems to work fine. What am I missing here?

ssokolow, (edited )
@ssokolow@lemmy.ml avatar

Lemmy hangs whenever I try to post my response (I suspect it doesn’t like the length), so here’s a link to it on Github Gist:

gist.github.com/…/16c9311573eabc7343ff7ff2cc3513b…

It begins as follows and I’ve tried to hyperlink my sources as often as possible:

I’ll try to fill in some of the knowledge gaps and respond to some of your answers from a more user-centric perspective.

buzz, (edited )
@buzz@lemmy.world avatar

Screenshotting apps and screen sharing still doesnt work on Wayland, I’m beginning to worry the rumours on Wayland inadequacy maybe real.

crypto,

@theshatterstone54 @buzz The rumors are real. I've tested Wayland on several distros on several machines and it has always been a disaster. On Debian Bookworm KDE on a FRESH install, the first thing I did was open the Discover app and it crashed. Every time I opened it the compositor took a dump.

Wayland is garbage and its apologists have an agenda. Their agenda does not include working software.

gustulus,

Skill issue

dzaima, (edited )

As someone who has written client code targetting X11, it’s indeed quite unfortunate that, to properly target Wayland, it’d need to all be replaced, but… good riddance. Working with X11 was fucking hell. X11 has so much broken/unreasonable garbage in, like, most places. Working with X11 has been, by far, my programming worst experience.

This is not to say that Wayland is automatically better at everything (I haven’t looked into it much, and the server-side decoration problem is indeed a problem) but it’d be damn hard to be worse than X11 or be anywhere close to it.

Raspin,

Just use libdecor. Client is supposed to manage its content.

dzaima, (edited )

Yeah, I’ve seen libdecor as a solution, but it still feels quite off to have pretty much every wayland client have a whole dependency for such a trivial thing.

Yes, the client is supposed to manage the client content, but the obvious question then is whether the window decorations are part of its content. In some cases (stuff merged into the decorations) it can definitely be the case, but, for most things I’d say the decorations are as much a part of the client content as the apps entry in the taskbar (both contain the title of the app, potentially the icon, options to close/maximize/minimize). The only difference is that decorations always appear immediately above a window, but even that isn’t really a fundamental part.

LeFantome,

I have noticed that one of the groups that does not seem to be complaining about Wayland are the toolkit folks. GTK added support back in GTK3. Qt added it. Enlightenment added it. They must have jumped on it for a reason.

When you look at the Wayland readiness docs for things like XFCE, it stands out that all the apps are already ready ( because they are GTK based in this case ).

dzaima, (edited )

Looked into some more things, and… base wayland does seem to continue the trend of “lol no not allowing you to do a basic thing, because surely noone has a good reason to” more - no custom positioning of windows (remembering custom window positions on reopen, window moving segments of Rhythm doctor), cursor wrapping (amazing to use in blender, wish more things did it, it feels so much better to use than the cursor being temporarily frozen in place or moving freely through everything).

At least there’s still the chance for extensions (wayland.app/…/pointer-constraints-unstable-v1 plus wayland.app/…/relative-pointer-unstable-v1 I think provide the ability to set the cursor position on wrapping and have that not interrupt the stream of relative position changes) but with things not being in base wayland it means that apps can’t just assume basic features on linux wayland which they can everywhere else (windows, mac, X11) unless they just choose to ignore hypothetical WMs which refuse to implement them.

I believe I also have a situation where ydotool wouldn’t be sufficient too - namely, having scrcpy open in the background and sending it keypresses to play/pause/change volume of the content on my phone from global keypresses (which trigger a shell script that chooses to either forward the presses to scrcpy, or if it’s not open, do some hacks to do what they would have done if not intercepted).

hellvolution,
@hellvolution@lemmygrad.ml avatar

Don’t spread lies; Wayland is not the default on Debian; nor on Stable, Testing, Sid or experimental

Scyther,

Debian GNOME uses Wayland by default

snor10,

I’ll switch to Wayland when XFCE makes the switch. For now, X is sufficient for me.

zjaume,

In what kind of world is a missing feature or a broken feautre due to incomplete migration to a new ecosystem, a reason to boycott that new ecosystem?? Those are simply not valid arguments to me.

They are obviously valid arguments to say, hey, this work is not completed, is not mature enough etc. So, therefore, you stay with previous ecosystem. But to boycott it because of that? That does not make sense to me at all.

PlexSheep,

Good post.

Despite all the progress in terms of Wayland, I still find my laptop to be unstable with plasma + Wayland on fedora 38. Many visual bugs, when the screensaver is entered and I move my mouse again, the screen just stays black until I close and open the lid.

Some booting and spontaneous shutdown issues too, but I assume that’s something else. (Framework 12 DIY)

ReveredOxygen,
@ReveredOxygen@sh.itjust.works avatar

Wayland limits me more than I’d like, with no global hotkeys and general low hackability. The only thing keeping me on it is the fact that I can’t figure out how to get fractional scaling on gnome xorg (also on fedora on a framework)

PlexSheep,

Scaling is one of the major things that suck. Probably on xorg too through. And especially with multiple screens in different ratios and uncommon ratios (like the frameworks 2:3 one)

loopgru,

Yeah, same experience on Wayland + GNOME for me. I want it to work, but stuff just breaks too often for me to accept at this point. How much of that is Wayland and how much of it is other things failing to work properly with it is kind of immaterial. Regardless, I’ll happily jump ship when it’s more baked, but now isn’t that time.

cybersandwich,

I would count myself among the people who dont have a huge attachment to x11 and am excited by the modern approach provided by wayland.

Ultimately, I just want my stuff to work. I am running pop and I tried booting into wayland, since they provide that as an option, but I was getting hardlocks. Something I haven’t had on a PC in over a decade. According to the log files it appeared to be related to wayland, so I switched back to x11 and haven’t had any issues since.

I am happy to switch to wayland, but I’ll be waiting on the pop devs to make it a focus–presumably after cosmic DE is out.

shrugal,

XKCD#1172 is very relevant here.

LeFantome,

Very

Dekkia,
@Dekkia@this.doesnotcut.it avatar

Wayland break games

The Steam Deck uses wayland so I guess that’s not true (anymore?)

arthur,

Valve created gamescope, that’s a microcompositor just for games. Other Wayland compositors may still break games.

flying_sheep,
@flying_sheep@lemmy.ml avatar

I was very sad when KDE reintroduced the concept of “primary screen”.

It used to just be the current screen, which meant that when I wanted to game or watch something on my projector, I just dragged steam or the folder with movies to the projector screen, then launched whatever I wanted, and it appeared on the screen I wanted it on.

Now I have to jerryrig kwin and a custom steam-in-gamescope Launcher to have games launch there. As a side effect, steam thinks my PC is a steam deck and therefore can’t be exited from inside of it, I have to right click the tray icon.

Horribly kludgy compared to “click launch game button on screen x, game opens on screen x”

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #