A response to the "Boycott Wayland" article

theshatterstone54@feddit.uk to Linux@lemmy.ml – 377 points –

Link to article: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277?permalink_comment_id=4749746

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, https://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: https://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

210

What a stupid article. It's like saying "stop using electric vehicles because you can't use gas stations". I don't understand why he's so adamant about this? It's not like Wayland had about 20 years of extra time to develop like X11. People keep working on it, and it takes time to polish things.

The article is 3 years old and some things are only presently being fixed NOW and due to filter down to stable distros in 2024. Furthermore wayland proponents have been claiming its totally ready for prime time and not broken at all since 2015 while promoting AMD GPUs that at that point in time still sucked hairy balls.

As someone with 0 investment in this whole ecosystem, I saw and perused this article like a week ago, and my immediate impression was "Why is this guy constantly saying 'Wayland breaks XXXXX'? Wayland isn't breaking anything, it's new tech. Wayland has certain features, or it doesn't or doesn't yet. The only folks breaking anything are those swapping use of X with Wayland, within various apps or tech stacks, potentially prematurely, where Wayland doesn't yet have the full set of features needed."

Whoever this is seems to have a really poor understanding of long-term software development, despite being way more invested in it than I am.

Wow, I couldn't have put this better myself. This is basically the short and simple versions of most of these arguments.

It feels like "English is broken because my friend only knows German." to me. English works just fine. Teach your friend English.

English is Wayland. German is X11. Friend is software.

You forgot the part where they don't need Wayland and its reduced features, because everything works fine in Xorg.

Stop pushing people towards Wayland, let it happen naturally when it will be ready and better, and they'll come. Trying to force adoption will just make people resent it.

because everything works fine in Xorg.

... for you. I got the honor to try to find the correct match of specific NVIDIA driver version, desktop environment and compositor to get anything even remotely usable back when NVIDIA only supported Xorg. I was greeted with either an entire crash, black screen, graphical glitches, and/or screen flickering if I forgot to pin package versions. Connecting displays from right to left crashed everything, so I was forced to change my display setup to left to right. Of course, waking up displays from sleep never worked either. So don't pretend that Wayland is a broken mess while abandonware Xorg is our Lord and savior.

Stop pushing people towards Wayland, let it happen naturally when it will be ready and better, and they’ll come. Trying to force adoption will just make people resent it.

Software vendors drag their feet to adopt Wayland as nobody forces them to adopt Wayland. Again, Wayland works fine. X11 features don't work in Wayland. But Wayland isn't X11. Xwayland solves a lot of these problems. Software vendors back then didn't port their Windows software to OS/2 due to OS/2's Windows compatibility. Video game publishers today don't port their games to Linux in part due to Steam Proton. Software vendors today don't port their X11 software to Wayland due to Xwayland. So the ideal solution is to force a critical mass to adopt Wayland, drop Xwayland, and let software vendors suffer from the consequences of ignoring 16 years of Linux desktop protocol innovation.

I'm glad Wayland solves problems for you, but it creates them for others.

Imagine being forced to go the other way. Could you be coerced into going back to Xorg? What would you do if a distro attempted to do that to you?

If people give up on maintainable solutions like Wayland, then there's no way in hell anyone picks up Xorg ever again. My Xorg issues remain wontfix. Wayland issues are now wontfix. Nobody works on Wayland and Xorg. Linux desktop is officially dead. I either switch back to Windows or buy a MacBook. I won't invest time into an ecosystem that's destined to die a slow, but guaranteed death.

I'm sure a lot of people try to hold onto their beloved abandonware to keep their Linux desktop alive, but why should AMD, Intel and NVIDIA care about Linux desktop now that the Linux community doesn't have enough fucks to give to maintain Linux desktop? May as well save driver development costs and drop Wayland and Xorg support from future graphics cards.

but why should AMD, Intel and NVIDIA care about Linux desktop

They care because it's free testing for their more lucrative Linux-based products. We're their lab rats.

You forgot the part where this is what is happening.

The Linux ecosystem is not the product of a giant corporation. It is highly distributed and both built and promoted by multiple players with many different goals and interests.

The people actually building the ecosystem have aligned almost completely on Wayland. The strong implication is that X was not working for them.

Distributions have been slower to move but that is happening now. You can look at this as forcing users to move. My guess is that it is more a case of pleasing some uses and frustrating others where more users want what Wayland provides than miss what it doesn’t.

It is always painful to be a laggard during a technology transition. There is usually a period where the new tech becomes common before it does what you want. That is just what technology transitions look like. When that happens, the problem is that the majority is perfectly happy and maybe happier than ever. That is why things happen when they do.

You forgot the part where this is what is happening.

All I see is a rift in the community over one side pushing software that's beta-quality at best, and acting very arrogant and dismissive towards real adoption impediments.

Which is par for the course for Linux, naturally, but "it's happening" is wishful thinking at this stage. At this rate and with this attitude it will take at least another 5 years.

Wayland's worst enemy is its own fans.

As I like to stay evidence driven, I should say that I use XFCE mostly and, as such, am not typically a Wayland user on most of my machines. I will let other readers decide how that impacts the indictment “Wayland’s worst enemy is its fans”.

I am not sure what the “sides” are here either. If I was to try to draw that line, it seems to be between people providing software and those using it. Because the people writing the software are moving to Wayland.

Which leads us to “at this rate”. GNOME and KDE will both be Wayland only next year. What percentage of the Linux Desktop population do we think that represents right there? Enlightenment has already moved. Ubuntu uses Wayland. Red Hat uses Wayland. The Steam Deck uses Wayland. XFCE and Cinnamon will move next year. Wayland only window managers are appearing and gaining in popularity. What percentage of the Linux Desktop universe are you expecting will still be using X at the end of 2025?

Some people may wait 5 years. Then again, Ref Hat will have stopped contribute to X by then and, as I said, nobody is rushing in to dev X. How long is running X going to stay viable?

I would say that BSD may take a little longer but they are starting to move too.

Liking Wayland or not has nothing to do with any of these facts.

They aren't facts, again, they're wishful thinking. I'm a long time contributor and developer and I can assure you that with things as complex as X and Wayland things would move slowly even if everybody was of the same mind, let alone in the "herding cats" style of FOSS.

Wayland has been in development for 15 years and it's still not ready – please, it's not, and stomping our feet and claiming otherwise won't make it so. Another 5 years will probably see it reach a more stable state.

What do I mean by ready? Well the desktop stack [on Linux and *NIX] is extremely complex. Whenever you're dealing with something extremely complex in software, over the years, you amass a large amount of solutions that solve real world problems. That's what I call "ready". Most of those solutions will be dealing with quirks and use cases which do not affect everybody equally, but they're each crucial in their own way to a varying slice of the userbase.

Whenever you rewrite something from scratch you throw away the bulk of those quirks. It's a common fallacy for developers to look at the shiny new thing and think that it's better. In reality it's worthless without the quirks, and accumulating those quirks all over again takes a long time. X has been accumulating them for 40 years. Wayland is barely scratching the surface.

The fact the protocol places and splits the burden over the various DE and WM teams will NOT help. We will need libraries that solve the same problem once instead of over and over, and most DE/WM will come to depend on those libraries. The end result will be eerily similar to X. Ironically, by the time Wayland will be done it will have spent a comparable time in development to X, and will have accumulated the same amount of baggage that people dislike about X.

What percentage of the Linux Desktop universe are you expecting will still be using X at the end of 2025?

More or less the same that's using X right now. GNOME, KDE and the various distros will get a bloody nose trying to force Wayland through but if that's the only way they learn, so be it.

The Steam Deck actually has one of the few use cases where Wayland actually makes sense, it's a turnkey, highly controlled stack (both software and hardware) where users don't have any reasons to care about what's under the hood. I expect them to switch ASAP.

Another place where Wayland can be used straightaway is the desktop graphical login screen (which is the original reason it was created for anyway). It's a singular application with reduced requirements and simplistic interactions.

It would be great it implementations had a full set of features 15 years in just saying.

That is why I never switched to Linux. I mean, it is over 30 years now and it still doesn’t do everything. Sure it does some cool stuff—but not “everything” I could do before. What is taking them so long?

I mean, really great point.

"Linux" is not an entity with well defined goals, it's a community that mostly does whatever it wants. That has the fortunate side effect of producing labors of love in software, that prove really useful in the real world. But it also ignores things like user experience, which affect things like the desktop the most.

On Linux the user is a second-class citizen, because worth in the community is determined by how much a person contributes (in code, testing, artwork, documentation etc.)

The Linux mindset is best expressed by a quote from Simon Travaglia (which I paraphrase because I don't remember it verbatim): "We're tasked with the well-being of the servers, not the users. They're lucky we even let them log in since users technically upset the smooth operation of the servers."

I switched to using Linux in 2003 and have by my assessment got quite a bit of value over the last 20 years maybe you shouldn't have waited?

TLDR of linked gist: wayland is not X therefore it is bad. end of.

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?

also, https://github.com/bugaevc/wl-clipboard. perhaps all OP (of gist) needs is a simple shim that can convert calls to xclip to wl-copy/paste? that doesn't seem too hard to make compared to keeping X.org alive I'd say (perhaps they should try making it if it's that much of a problem)

Wayland breaks screensavers: Yeah, that seems to be the case.

from the dev of xscreensaver at https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/ :

[...] Adding screen savers to Wayland is not simply a matter of "port the XScreenSaver daemon", because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. [...]

[...] Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11. [...]

other people can comment on the parts they know about, these are two i know of off the top of my head

Who even uses screensavers these days?

businesses that want to put their logo or slogan bouncing around on monitors of inactive computers

that's about it

I still install the MatrixGL screensaver every once in a while for shits and giggles on a new install until the gimmick wears out.

Screen locking has obvious use cases.

Screen locking yes, but that’s not screen saver.

In the modern era, the main purpose of a screen saver is to lock the screen, and has been for most users for a long time. Many of us would also like to have pretty pictures on our locked screens.

It no longer has anything to do with preventing burn-in, so you're right from a certain point of view.

I dunno, my OLED panel has some notable image retention issues - and a screensaver does appear to help in that regard.

But locking the screen is not the purpose of xscreensaver. It’s mostly just an overlay with animations.

To quote its author

On X11 systems, XScreenSaver is two things: it is both a large collection of screen savers; and it is also the framework for blanking and locking the screen.

Eh, I went back to screen savers due to my use of OLED panels. Better than a static lock-screen image for sure.

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.

Posting this from Plasma Wayland on Intel right now. If something is broken, it's something not apparent to me.

No problem with GNOME and hyprland here, on 2 different laptops.

Dual monitor? Wayland on my intel works fine for single screen, but as soon as I plug in a 4k monitor, it gets black cube shadow like artifacts in KDE Plasma 5. A couple of kernel command line options for the module has not helped, either.

I'm fairly sure I have run this system dual-monitor though I don't do it routinely. I'll check sometime this weekend and let you know, if you are interested for comparison's sake.

I most certainly am. :)

I've just finished watching Generation Kill on a Thinkpad T480s (i7-8650u). It was plugged into the TV, and it plus the laptops screen worked fine.

Running arch, gnome, waylandVideoSnapshot_20231118_062333

Imagepipe_0

Worked with no drama, for me at least. Hooked it to my TV because that was most convenient. USB-C to HDMI adapter, I just had to tell it where they were in relation to each other and set scaling on the TV. Fonts look a little screwy on that dialogue box, but only in the screenshot - and when composing this post I realized even there they look OK if I don't view that part of the screenshot on the 4K display.

Edit: No, untrue. I think I had the wrong glasses on. The fonts on the 1080p display are fine in reality, but the screenshot is distorting everything on that panel a bit. Again, screenshot only though. All good otherwise. I can't see any other problem after using it a bit like this though.

I would love to see your kernel options line from grub, assuming it doesn't have any secrets in it. Please.

No problem, I've done no magic of any kind there. This is what the manjaro installer created only.

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64 root=UUID=99ed8aec-cdfc-44d6-8217-c85d3db09036 rw quiet cryptdevice=UUID=9bca8872-3f01-472a-b196-ef19cde6b5f8:luks-9bca8872-3f01-472a-b196-ef19cde6b5f8 root=/dev/mapper/luks-9bca8872-3f01-472a-b196-ef19cde6b5f8 udev.log_priority=3

Thank you. I figured there be some modeset style options, but nah, you have none. I consider you quite lucky and admit to being a little jealous. :)

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.

Maybe not anymore in the future: https://blog.davidedmundson.co.uk/blog/qt6\_wayland\_robustness/

Wayland is biased towards Linux and breaks BSD

FreeBSD already has working Wayland compositors by the way.

Oh yeah, I forgot about the work on Plasma and QT6.

I didn't know that about FreeBSD. Will add it.

FreeBSD's Wayland support is through a Linux compatibility library. The major Wayland implementations are Linux only and there's no way around it other than implementing Linux libraries like FreeBSD did.

That something entirely different than the protocol being biased towards Linux. It's like complaining that TCP/IP is biased towards Linux because the Linux kernel's networking module can't be used in BSD kernels.

Clearly biased towards BSD as both MacOS and Windows started off with the BSD TCP/IP stack.

Many operating systems use the WiFi from BSD as well.

Wayland break games

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

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

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”

  • Wayland breaks in-home streaming: Not familiar with this, so will assume true.

False. Sunshine works perfectly on Wayland, and last I checked Steam's in-home streaming works fine on AMD/Intel, it's an nvidia driver thing.

The only thing I can't get working on Sunshine on Wayland is a visible mouse cursor. Makes streaming Baldur's Gate 3 with a cursor a pain.

Thats a Sunshine issue, happens to me on both Wayland and X.

Try disabling hardware cursor on your respective DE, it fixed the issue on my machine.

I used to be super excited about Wayland but it's been 15 years, now I'm too old to care.

My favorite distro still runs on xorg and it runs so well that I don't remember why we needed Wayland in the first place. (I am not saying that there is none)

Tearing videos and games have been fixed on xorg when Wayland was supposed to be the only solution.

I am sure Wayland will eventually make X completely obsolete and will be a much needed modernisation of the Linux desktop stack.

But I can't help but notice that it is not there yet, is old enough to carry it's own significant technical debt and might never bring the simplification and streamlining that it once promised.

Yeah, I don't see a reason to use Wayland unless it's a drop-in replacement for X.

I don't have any issues with X. I'm glad it works and I don't even know it's there.

It doesn't make sense for me to adopt something newer that works worse when I have something that works without issue right now.

I bet when Wayland reaches the maturity, adoption, and stability of X, people are going to be moving to the next broken thing that will be functional in 15+ years.

Have you ever heard of Velox ( based on SWC )?

It is a tiling Wayland compositor that is only a couple of megs in size. On Oasis Linux, I launched into Velox, opened a terminal, and checked the memory usage. It was under 30 MB of RAM. That is for the whole system!

That experience made me think differently about Wayland.

There was only one Xorg. For me, the evidence that it was big and complicated is best expressed by the fact that, over decades, the number of projects that competed to provide X had dwindled to one. There was loads of unhappiness with it and yet, there were no forks. Why?

Now Wayland. There are new Wayland compositors all the time now. I just saw one yesterday—Louvre. The basis for Velox above is SWC. There is Wayfire. There is Weston. There is of course wlroots. And both KDE and GNOME have made their own. I think somebody even wrote one for Haiku! For me, this is evidence in itself that making a Wayland compositor is easier than implementing X.

It also means that all these Wayland compositors can compete with each other and drive each other. It means that I, as the end user, can pick a super stripped down version when that is what I want and an all-singing, all-dancing version when that is what I want instead. In some situations I will be happy with, and thankful for, Velox and in other situations I will want GNOME.

It is taking a long time and the journey has not been smooth. That said, I am becoming quite confident that we are in a much better place. For normal uses, Wayland is in a good place now. The level of innovation is very high. Dev can start to shift from the basics to the extras. I fully expect that we are heading into an exciting time on the Linux desktop.

X has a singular fully functional implementation into which you can slot a wide variety of components. Because everything is a component that slots into the singular X implementation forking has both a low benefit and a high cost.

Wayland is just a protocol everyone must implement with a semi useless reference implementation that nobody would ever use. Nobody forks Wayland they just implement it as they must the X approach isn't available.

It's apples to oranges. A meaningless comparison. Its more just churn than innovation on the part of desktops.

Maybe.

That said, everything you said about the Xorg server could be said about wlroots. Nobody has to “implement Wayland because they must” anymore. The X approach is available in Wayland as you can build your window manager on top of wlroots and many do.

Seems fairly apples to apples to me.

Or you can choose a competing compositor library as there are now quite a few available. I think XFCE is looking at using Wayfire. Or you can control more of the stack directly and write your own as GNOME and KDE are doing.

Not only do you not have to implement Wayland to make a window manager, because compositor libraries are available, but people are writing Wayland compositors even though they do not have to. Louvre is a compositor recently released that seems expressly designed to make writing new window managers super easy.

As for innovation, there seems to be lots in Wayland. Valve just added HDR. GTK is looking at using dmabuf. There are already Wayland window managers that are not ports from X. There seems to be innovation at every level.

Building on top of wlroots is still a different scope of problem than writing a window manager for X. Pretending its the same thing doesn't change the fundamentally different architecture even if it certainly makes it easier.

Out of all the libraries isn't recent KDE the only fucking one that supports proper scaling of xwayland windows without turning it into a blurry mess? KDE which nice as it is lacks most of the nice tiling features of i3wm or the per monitor workspaces? Let me rip out and throw away a highly functional Nvidia GPU and come on down!

Don't worry in another fucking 10 years all problems will be solved in the meanwhile I'll just be fucking using non-beta software. Pardon me if I'm a little annoyed. Wayland has been the future for a while now.

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.

Wayland ... uses some Linux-specific components or libraries

No. Wayland is a protocol, not software.

Yeah, I was going to ask if the Wayland protocol included some Linux-kernel-specific data structures or something that would make it somehow more awkward to implement on non-Linux kernels or something.

Like if I created a protocol that included sending data encoded using the Python serialization framework called "pickle", one could say that was a Python-specific protocol in that while it would be possible to use that protocol from other languages, it would be very weird and awkward to do so at best.

Not really knowing much about the specifics of Wayland, I wouldn't truly know if there could possibly be anything Linux-specific in Wayland. But as far as I know, it's entirely possible theshatterstone54 knows something I don't.

What they are talking about is that some of the Wayland compositors rely on things like libinput and libdrm which are Linux specific.

This is not “Wayland” really but, from the point of view of a regular user, it may as well be. As the OP points out, there is no /usr/bin/Wayland

It is not really a great criticism although it must be frustrating for the BSD folks and others. Of course, the answer like always is to contribute. Nothing stopping anybody from taking wlroots ( or whatever ) and adding abstractions that make it more portable.

Non-Linux operating systems have already added Wayland support ( like Haiku ). If I had the time, I would add it to SerenityOS myself.

Actually, if I had the time, I might write a WaylandServer for X. First, it would be funny. Second, the people that do not want to move could stay on X forever even when everything stops supporting it. I would have to make sure that my WaylandServer could run XWayland of course.

xorg is going to die eventually. probably long after the xorg fanbois, but it will die - and wayland or something better will take its place.

I'm okay if Xorg dies off. I just hope that the stuff I use everyday works reliably with Wayland before it does.

I'm glad to have some of the more reasonable Xorg users express their opinions here. I share in this opinion.

If I remember, there was another display protocol being developed as an answer to Wayland for BSD. I don't remember what it was called, but that project was basically about an open source MacOS.

OpenBSD, NetBSD and FreeBSD all support or are planning to support Wayland.

RavynOS?

I think the predecessors to RavynOS, it was called HelloSystem I think. In that project, they were talking about an alternative display server protocol.

Man. That is a fair and well thought over response.

I appreciate this! Articles like this is what I'm on lemmy for!

Because calling your post a response would not do it justice enough. An article indeed.

♥️

all of these arguments are great and all but as an enduser: I just want things to work

I don't care about the why's or hows. A lot of these arguments explain and justify breakage

I am an enduser. I expect things to work, specifically I expect the programs I already use to continue working. I expect to lose no functionality

If they don't work, then clearly its broken. If I lose functionality, Wayland clearly wasn't ready

Wayland is ready for most people. You're free to keep using X11 if your use case isn't covered yet.

If they don't work, then clearly its broken.

Protocols are fine. Clients may speak one or another protocol. But protocols aren't broken when clients designed to speak one protocol fail to speak a different protocol. It's like saying English is broken because my friend only knows German, except English is Wayland, German is X11 and my friend is clients. Wayland is always ready to listen to clients that speak Wayland.

Yeah, especially the argument about Wayland compositors taking down all apps with them when they crash: that's just bad, no need to sugarcoat that.

A better argument would be that it's not true: KWin keeps Qt apps alive, and they're working on extending that to all apps. As a result, in the only crash I've experienced, I only lost my Firefox window, and zero data as all my tabs and form entry values got restored when I started it again.

As someone once said: "The Technical Merits of Wayland Are Mostly Irrelevant"

But Wayland's technical merits are relevant in a subtle way. Wayland is maintainable. Xorg isn't. That's it, the single most important technical merit. Everyone works on Wayland. Nobody works on Xorg. If people decide to use X11 today, their issues are wontfix with the solution to use Wayland instead. They can't fix the issues themselves because X11 is an unmaintainable mess. Xorg is on life support with the only purpose to serve Xwayland.

For the four groups enumerated in the article, this still is not important. It may affect them in ways they are unaware of, but you will not be able to change their minds using technical arguments at this point if they have not already been convinced by the wealth of information and support that is readily available.

for the end user, that is irrelevant

They hated her for she spoke the truth. We (DIY people) hate to acknowledge that not everyone sees value in investing as much time and energy into perfecting their workspaces as the nerds have, and would rather have their tools Just Work(tm) so they can get to work on the projects they do care about. I say this as someone who still gets frustrated and argumentative when my friends say they prefer spyware-ridden OSes that remove control from the end-user because they don't require end-user micro-management to maintain and work.

X vs Wayland might as well be Grub vs rEFInd or systemd vs SysVinit to most end-users: it matters from a technical perspective, but most people just want something that will allow them to go about their business without sinking hours into getting the "correct" option to work. And it's important to remember that we all fall on either side of this divide with some aspects of our life, even if it's not computer-related. How often do we agonize over finding the "correct" pipe wrench when our sink is leaking, despite what the plumbing nerds would criticize you for using? Do you sink hours into picking the right books on conflict resolution when you argue with your spouse, or do you post on AITA and hope they give good advice? Do you agonize over having all the right utensils and ingredients so you can eke out the most subtle flavors from your cooking, or do you use the pan that you got at the local superstore?

I'm not a she but otherwise yes I agree

???

Please explain

The same wayland bait is posted every week from new ban evading accounts which eventually also get banned.
They keep coming and getting shown the door, like Barney here.

The worst part is that person is using the Wayland bait to push anti-trans propaganda.

Yea, don't hesitate to report them.
Honestly, I literally couldn't give a shit that anyone criticizes Wayland itself, but they're a generally toxic user that's easily recognizable by their constant hateboner for Wayland (among other things).

Wayland is great! Except for all list of not-a-bugs that I'd like to see fixed. Still, I'm not going back to X, so take that how you will.

What are the not-a-bugs? Things like covering up a Wayland window will block it's rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don't want applications to know if their window is visible or not because it's mild information about a user's attention that should be private. Every game dev on the other hand is asking "WTF!?" as it causes their games to break randomly.

Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can't pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can't open and focus URL in your web or file browser. Instead they have to give you a notification telling you "Firefox is Ready" and make you do it manually.

A lot of this is slowly (painfully?) changing, and the adversarial nature is a bit frustrating. Wayland fixes so many little things that I find it well worth it though, and I say that as a game developer frustrated by many of the core design decisions.

Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can't pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can't open and focus URL in your web or file browser. Instead they have to give you a notification telling you "Firefox is Ready" and make you do it manually.

I would like them to keep that behaviour. At least make it an option or allow whitelisting certain applications. Nothing I hate more in an OS than windows stealing focus without asking.

Focus stealing is one of the worst things in the world, I am so glad I haven't had to deal with it since I switched to wayland. (Except for stupid firefox tabs stealing focus from other tabs, that still happens obviously and happened to me during a test for my university and almost invalidated my score)

Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private.

I do like that. I have encountered a number of bullshit things like HR mindless training videos (ok, the fourth time I've seen this guy contemplate accepting a bribe... I get it. Don't accept bribes! Leave that shit to Clarence Thomas) or ad playbacks that refuse to proceed unless they are focused. It's annoying as hell. The problem you point out also sounds really annoying.

What are the not-a-bugs? Things like covering up a Wayland window will block it's rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don't want applications to know if their window is visible or not because it's mild information about a user's attention that should be private. Every game dev on the other hand is asking "WTF!?" as it causes their games to break randomly

Please don't make up what "Wayland core folks" think. You don't know it, and your claims are waay off.

It's not about security. It was intended to allow the compositor to throttle apps to improve efficiency... Which of course in practice doesn't work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.

As for why that hasn't been fixed yet, it's not as big of a problem anymore:

  • Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
  • toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
  • xdg shell now contains a flag for apps to know to inhibit rendering because they're hidden. That doesn't guarantee that presentation won't otherwise block though
  • a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan

Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can't pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can't open and focus URL in your web or file browser. Instead they have to give you a notification telling you "Firefox is Ready" and make you do it manually.

That's not even close to how activation works on Wayland, and no, it's not just a security thing, it's a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can't cover up what you're working on just cause they need to show you an ad or an "important" pop up question or whatever. If it doesn't work for a specific app, make a bug report about it to the app.

A bit of a zombie thread, but I'm not making anything up here. The blocking issue gets discussed a lot in gamedev circles, and there are issue threads that have been locked by folks with the power to do so because they just said "no". One of them (Maybe Sebastian Wick? I don't remember... doesn't really matter) gave verbatim that use case where a video service they use would stop playing videos when the browser was in the background, and that is why they won't report . Maybe they weren't a "core" developer, but they had the ability to say "no" and end the discussion thread.

As for it being not a problem anymore, it still occurs even on Fedora 39. The 1 second present timeout still only works for XWayland, and that's... not a great solution. Also, realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don't have the time to worry about what GTK, Qt, or XDG shell does. We are already supporting multiple rendering APIs, and combining that with multiple UI libraries just to get a window to draw a triangle into is a combinatorial explosion. Last I remember reading from the SDL folks, they were waiting for the functionality to appear in Wayland before they could implement it, and they weren't expecting anything to change soon either. Speaking personally, my current game project is single player so I can just pave over the timing issues when they come up:

Long frame detected: 6463.731931 ms. Skipping ahead!

The most frustrating part to me is much more meta. You get discussions with other game devs that have heard about this stuff and they continue to think that supporting Linux is just way too much work. Sometimes they are right, but rarely for the right reasons it seems. I believe in the glorious Wayland future... I just wish it would get here a bit faster. ;) On the other hand, if we rushed it and botched it then it would never arrive at all I suppose. (sigh)

As for how window activation works, you got me there. I just heard other people discussing that one, but it did explain why on Wayland I would just get "Firefox is ready" notifications when opening links instead of just showing me the page like X did. Though I'm quite happy that it's gone now in Fedora 39. Progress is good!

The 1 second present timeout still only works for XWayland

Oof, I thought the corresponding MR for Wayland was merged... But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|

realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does

SDL does handle it, but only for OpenGL; it can't do anything about Vulkan. GLFW doesn't do anything about it either, so that is pretty annoying.

I believe in the glorious Wayland future… I just wish it would get here a bit faster

Don't we all. Let's hope the current upstream approach to fix this issue gets somewhere sooner than later...

Nvidia works on Wayland now. And in 6.6 the noveou will support reclocking on 2xxx+

Games also work fine under Wayland. Either with gamescope or kwin.

Mutter works well but they haven't yet merged vrr support so you have to get that separately.

Nvidia appeared fairly buggy as of nvidia 535 and kernel 6.3 with both sway and Plasma 5.27. Notably of all the possible choices for Wayland support ONLY KDE in relatively recent releases supports proper scaling of apps using xwayland which are apt to be a thing for a while now. This is a huge point in KDE's favor despite loving the idea of an i3 like experience with sway.

If prior experience bears out plasma 6.0 will be buggy as fuck and 6.2 will be excellent.

Nouveau has NEVER been a particularly good choice and its primary developer just resigned https://www.phoronix.com/news/Nouveau-Maintainer-Resigns I wouldn't pin my hopes on it in the future becoming usable. I sure as hell wouldn't say its a useful choice NOW because you suppose it may become so in the future. I'd rather look at nvidias official open source effort.

If I had a crystal ball to look in I bet it would say a lot of folks with existing Nvidia hardware are best off sticking with X11 in 2023 but looking again at KDE's wayland session in 2024.

Although do bear in mind people using stable distros like Ubuntu/Mint/Debian will be a lot longer seeing new useful features pushed out.

I always interpreted that as a factor of the Plasma team being willing to offer compatibility for things that broke the freedesktop spec.

Whereas Gnome / Mutter for example appear to believe that if they don't strictly follow spec it'll perpetuate the fragmentation.

I tend to side with the latter perspective but use KDE + kwin on my desktop for gaming for Wayland + vrr (it's amazing how smooth and responsive this is). Gnome really shines on the notebook form factor so I use it there.

NVidia user here, it most certainly is not working well. My external monitor for my laptop is getting black boxes shadowing the kde menu and most of my windows on that screen, and often block boxes trailing the mouse.

Add screensavers or take X11 out of my cold, dead hands. I don't use a CRT but still like screensaver since it prevents me from having to wait 5 years for my screen to turn on.

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.

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

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 (https://wayland.app/protocols/pointer-constraints-unstable-v1 plus https://wayland.app/protocols/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).

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

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.

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)

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.

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.

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)

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)

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?

idk i feel the window manager space its losing a lot with wayland and i didnt have a great experience with any wayland versions of existing WM. without even talking about the nvidia shitshow, does sway still call you a bitch for even trying to run it on nvidia?? imma stick to dwm as long as it works

No, running sway with the --unsupported-gpu flag launches it without any remarks about your hardware. It's been like this for a good while.

I didn't have a great experience

Neither did I. I use Qtile, and I'm waiting for some things on Wayland to improve. It's close, but not there yet.

I think this is ultimately the answer. I'm not going to judge wayland until I see it as ready and can truly replace X in all use cases.

I sometimes feel like the distros switching now is premature. But, maybe they know something I don't.

Fedora is switching because Fedora is always trying to be first at everything. And because things are very close tp perfect, it means that when Fedora makes the switch, a bunch of users will use Wayland more, helping iron out the last few bugs and issues.

I believe they try to force it asap to make pressure on applications developers to really speed things up.

When I dumped windows for the first time (maybe about 5-6 years ago) I immediately stumbled upon articles about bad wayland needing decades to mature. And here I am couple years later running linux on wayland quite happily.

i just tried again, its literally impossibile to compile dwl on ubuntu 22 since libwlroots-dev is too old so youd have to compile that manually... stuff like this is what keeps me away from wayland for now

I tried on Debian 12 a few months ago and failed.

yeah you need wlroots 16 which is not there, trying now to compile from source but you also need to compile wayland manually...

edit

tried anyway and after compiling libdrm wayland-server pixman and other stuff i give up. this is not worth it

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

Not disagreeing at all, but I'd like to add some information here to support your correction

There's a GlobalShortcuts portal ( https://flatpak.github.io/xdg-desktop-portal/docs/#gdbus-org.freedesktop.impl.portal.GlobalShortcuts ), and this is implemented for hyprland in xdg-desktop-portal-hyprland ( https://github.com/hyprwm/xdg-desktop-portal-hyprland/blob/b2fc1110963fa583ad5348a9dc0101bd58ceac7a/hyprland.portal#L3 )

So, technically, there is nothing in the wayland collection of protocols that supports global keyboard shortcuts, but (along with lots of other supporting functionality), this is addressed via the collection of portal APIs

As it happens, KDE already supports the GlobalShortcuts portal: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/data/kde.portal#L3

Any desktop can provide an implementation of the GlobalShortcuts portal, and any app can adopt it as required (although if it's implemented within popular toolkits/frameworks, then app developers won't have to even think about it)

Here are related tracking issues:

Sadly, this is going to be preaching to the choir. Wayland has its faults but if it truly was an inferior approach compared to X then someone would've forked X or spawned a totally new project. Turns out it takes time, money, and developer power that simply isn't coming into X or any competing standard. Wayland is "good enough" to be the next standard and that's how it'll be for the foreseeable future.

If a BSD fan really thinks X is pivotal to BSD's future, then maybe BSD will need to consider forking it and fixing it, but I'm sure the real solution will just be supporting Wayland on BSD too.

Not only is nobody forking X but many people are building Wayland compositors.

Listening to the detractors, you get the impression that Wayland is a failure and / or that X may still be the better choice.

Then you realize the only people still working on X are paid by enterprise distros with long-term support obligations. All the toolkit people have moved to Wayland. The major desktop environments have shifted to Wayland. All the “new” window managers are for Wayland.

Wayland is already supported on BSD ( FreeBSD at least ).

The actual developers have spoken and Wayland has won.

For most of its 15 year history implementations have been woefully and obviously insufficient. Nobody forked X because nobody needed to. Its feature complete and has been for a long time and there was nothing wrong with using X while Wayland implementations see progressive improvement.

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.

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?

Amazing text! I was just commenting how ridiculous the article is this morning and now you have written a more lenghty criticism.

As for the Zoom bit. I will add my 2 years experience of using it on Wayland on Artix as well as Void Linux - I never used Gnome and it worked fine on Sway and River on my iGPU. In between a few updates I did face a few crashes of zoom when rendering on my nvidia gpu but it was still fine. I have not used zoom in over an year so I can't comment on how it is now.

As for "wayland does not work properly on nvidia." Solely nvidia is blame. They have been pushing out patches to bring out more support but it's just nvidia who can fix that in the end. While I would not want to assume what hardware the author uses. Wayland works like butter on my Intel hardware.

Great alternatives for xclip and many other X-tools are already in the market.

The VSync issue on wayland is genuine. Disabling it in-game does not affect anything because it is enforced by the compositor. VSync is an integral part of Wayland Compositioning (acc. to the wlroots dev) but a solution to automatically disable it in full screen applications, etc is down the pipeline and work is ongoing. I have not been following it but I think some fixes were already released, I could be wrong.

As for X11 Atoms: https://stackoverflow.com/questions/41005297/x-to-wayland-what-about-atoms Just boils down to the application dev's willingness to port the app to Wayland. The author of the 'boycott wayland' article seems to just want wayland to implement Xorg 1:1 for it to not fail their stupid standard of what-should-be-boycotted. And at that point Wayland is not Wayland but Xorg.

Most of the arguments presented in the 'Boycott Wayland' article are either generic issues being worked upon by the devs or things that don't have much relevance but put down in a manner as if to almost fear-monger that Wayland is the spawn of the devil and must not be used at all.

As for “wayland does not work properly on nvidia.” Solely nvidia is blame.

Nobody but Wayland apologists cares who is to blame. If it doesn't work on their hardware that clearly is an issue with the idea that Wayland should completely replace X11/xorg because out of Wayland and Nvidia if one of those two goes away it will be Wayland, not Nvidia.

You clearly do not know what you are talking about so I have no interest in giving more value to your already worthless comment. It is amusing that you must introduce the term "Wayland Apologist" as if that has any meaning in this sector.

So I guess you don't have anything but insults then to refute that blame is at best a secondary issue and most likely a complete non-issue for people on whose systems Wayland won't work. Unless all you care about is playing blame games but not about the actual practical issues blame is irrelevant.

I mean, you started your comment by saying "Wayland apologists" - I'm not sure why you thought it would go over just fine.

Which is unfortunate that you did, the Linux community already has quite a bit of hate for Nvidia (for good reason) but comments like these tend to just make people who use Nvidia hardware look bad. I say this as someone who made the exact same position on the argument (so to speak) in a similar thread a few days ago.

Does Wayland allow for the running of a program on a big powerful server (where many users live) and display on a smaller desktop machine that is only providing a screen and keyboard? If not, are they working on that? If it does not and they are not working on it, is it even possible under the way that Wayland works?

Yes, with waypipe.

Waypipe is not Wayland. Wayland does not natively support this workflow, which is why Waypipe was created. Please don't confuse the two as being one thing.

Xrandr is not Xorg. Xorg does not support an easy way to set screen resolutions. That's why Xrandr was created.

You are giving me the impression that Waypipe is an extension to Wayland like XRANDR is to the X11 protocol. I didn't get that impression from the blogpost. I'm not trying to place value on them being an extension or a separate tool. I'm just trying to figure out if it was a shortheaded response or if Waypipe is an extension to the Wayland protocol.

This may be "moving the goal posts", if so I apologize in advance. With Waypipe can I have local windows and remote windows on my laptop? Will Waypipe work over a VPN (Tailscale is a VPN right?)

No. Wayland does not. That's why Waypipe was made to address that shortcoming.

Waypipe - Thanks I will look into that. Thanks to the others who also added their opinions promoting waypipe.

I'm pretty sure any distro setting up Wayland will be including Waypipe for you so your experience should be transparent.

I believe they explicitly don't support network transparency. The suggested alternative is to use a VNC client to connect remotely to the desktop.

I don't think a good response to " breaks " is to say "yes, because was designed to work with and hasn't been updated to use ". Part of the task of replacing something old - onerous though it be - is to provide a smooth route to support old programs and functionality.

Wayland deliberately broke everything, but then was rolled out prematurely at least on some distros, before giving the vast X ecosystem enough time (which was guaranteed to be a long time, due to how large and entrenched it was) to update. Besides which, the "OUTDATED" post has an awful lot of things you acknowledge are still issues!

The problem, as I see it, is that the author of the original Gist does not really want wayland replacements for what he has, but rather what he has to also work on wayland.

Wayland didn't break everything. It broke what relied on X11 specific stuff, which turned out to be a lot of things. The vast majority of issues still present with Wayland are edge-cases that will only see the light of day when the people with those edge-cases start using wayland. And as long as distros default to X11, that won't happen. So that distros, like Fedora, started defaulting to Wayland "early" on (yes I put early in quotes, because it's only perceived as early) is actually a good thing. Makes the compositor developers aware of edge-cases they can't catch themselves.

I'vge been using Wayland exclusively for over a year and apart from a couple of small bugs, not even missing functions, I haven't experienced any issues relating to Wayland directly. But that's for my use case. YMMV as always.

The problem, as I see it, is that the author of the original Gist does not really want wayland replacements for what he has, but rather what he has to also work on wayland.

It's like the Windows users expecting to use all the same software on Linux when they move over problem, but in microcosm.

The main issue here is not that some of the issues that are mentioned there are not genuine. They indeed are genuine and have mostly already been notified to the devs working on the protocols and the compositors. The issue here is how those are presented. By creating this almost cultish "battle between the 2 display servers" thing is not productive and demoralizes developers. Making criticism is one thing and productive but "boycotting" is not. And certainly not in the bad faith way the author of that article has done. I myself have both X and WL setups and I alternate between them frequently. I am not sitting here "boycotting" one display server in a prejudiced manner. This is Linux, not Windows or MacOS. Users are free to continue using Xorg and develop it according to them if they do not like something else. And similarly, they are free to use Wayland.

I would argue that promoting Wayland as production ready is still premature considering the number of excuses Wayland proponents have to make who is at fault for Wayland's shortcomings (Nvidia seems to be a big one but people who have needs the short-sighted protocol design didn't account for are a close second).

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

I now have perfect wayland setup with a Nvidia GPU. I just use my AMD Apu as main gpu and the nvidia one as secondary GPU. The DE runs on Amd and games run on Nvidia. Thanks for nothing Nvidia, making me work around your bs.

Wayland on intel is the same as it is on AMD, and has been for years now... I don't really get why they would say that it's broken...

I'm very new to the Wayland vs Xorg: could someone tell me why having a compositor work as a compositor, server and client (window manager) is a good idea? Doesn't this limit customisation? If someone wants to create a window manager, they're going to have to implement a lot more software than just their product. I thought abstracted software with stable interfaces was king in software, other than having performance issues (I believe Wayland solves some of these problems).

So, if I'm on IceWM/Ratpoison and want to switch, do I manually convert my config, or do I have equivalent WMs in Wayland?

There is nothing stopping a Wayland compositor from exposing an interface that would allow for a choice of "window manager". In fact, wlroots could almost count as such a compositor - it implements the bulk of a compositor, but none of the bits of a window manager. Of course, Plasma and Gnome also allow window managers to be integrated as plugins, but I presume that is not what you want.

It is not like the X window manager idea is impeccable either: To name one thing, picom or other compositors could display much nicer and context aware animations if only the window manager interface was not like it is.

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.

I still would have preffered a modular approach, where compositor, window manager, server/mouse+keyboard are plugable. Well, it's probably possible with Wayland, but the ecosystem is not there yet.

I'm pretty familiar with Linux server management, but haven't ran Linux on the desktop in a very long time (I still remember the days of XFree86, which was the predecessor to X.org). If I install a mainstream desktop distro today (Ubuntu, Mint, whatever is popular now), does it come with X11 or Wayland out-of-the-box?

Depends on which DE in which version it is using, but anything with recent Gnome (Fedora, Ubuntu) will. Not sure if KDE distros generally default to it, and for more niche DEs the answer is probably "no", unless it was explicitly made for Wayland.

I think GNOME is the only Wayland-first DE at the moment. KDE may go Wayland-only with Plasma 6 next year.

Most other environments are still X for the moment though most of the major ones are starting to at least implement Wayland.

There are Wayland only options like Hyperland, Sway, and Velox now too.

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.

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:

https://gist.github.com/ssokolow/16c9311573eabc7343ff7ff2cc3513b3

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.

Do the Wayland devs care about implementing network transparency yet?

I doubt it's ever going to be a part of the core protocols, but it doesn't have to be, you can just use Waypipe.

No, and I do not expect that they will. They consider it a feature independent of the window server. To them, it is a feature, not a bug.

It's hardly worthy of being called a "window server" if it isn't network transparent...

The only thing to boycott are GNOME dev's mentality when it comes to things outside their DE (especially Wayland protocol adoption). It's slowing Wayland development a lot

I agree. I am personally a fan of server side decorations. I use tiling Window managers which means I do not need to have extra buttons (browsers) or bars (looking at you, thunar) to close, minimise of fullscreen an app. Heck, one of the reasons to use a tiling wm is to maximise the usage of screen real estate and with these extra bars and buttons you're taking some of that away!

I didn’t read any of that but Wayland doesn’t work with xscreensaver so I’m not gonna switch to it.

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

I often switch between Wayland and X. My only concern is java does not yet support Wayland and old native libraries (e.g. 3D stuff for no longer maintained Java games) will probably break, once Java actually switches. Java and some Java games work with the xwayland compatibility layer, for now, but there are glitches sometimes. There are multiple projects porting Java stuff (e.g. Swing) to Wayland. All unofficial and incomplete.

There are some hacky methods to make some Java software use Wayland. Iirc, https://github.com/openjdk/wakefield is the jvm version I used to test it on Minecraft and Mindustry. I did not really get that far, but it has been quite some time since I tested it so I do not remember exactly what the results were. Otherwise it is possible the subjected software itself needs extra editing to make it work on Wayland.

Yeah, I don't know about Java. I often switch between X and Wayland myself, but I'm mostly on X because I use a tiling window manager (Qtile) which has a Wayland version but is still ironing out some issues before I can switch full time.

For some reason I had assumed that this would easily be handled by Java's write once run everywhere paradigm.

I think that's only true for the programs, not for the JVM/JRE code. The JVM/JRE doesn't support Wayland without the xwayland compatibility layer. Also, some games use "native" libs that do optimized 3D stuff. Those are special Java classes, not part of the JVM/JRE that interface with C libs, kernels, system calls and hardware directly. Some will stop working without an X window to connect to. Some are long forgotten and won't be ported.

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.

@theshatterstone54 > "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."

Not so. FreeBSD is 100% Linux compatible and has Linux Kernel emulation built in. Wayland support is also built in to FreeBSD. FreeBSD is a much superior operating system compared to Linux. But the FreeBSD team only cares about the server aspects and really does not care about a graphical desktop. They tend to use Macs.

FreeBSD Documentation Portal

The state of Linux Desktop interface is a schizophrenic flustercuck with far too many cooks spoiling the stew. They're not just spoiling the stew; they're pooping in it. And a bunch of noveu-riche trust-fund baby nerds think this is cool. They don't give a rat's ass about the end user being able to get work done. They would rather we all waste our time filing bug reports rather than getting things done.