I only started using "Desktop" linux about 2 years ago when I got my new Laptop. When I first started, I had no idea what the whole Xorg/Wayland story was up until that point. After a bit of research, I tried starting with i3, but could never get it configured correctly to use my laptop monitor and my desktop ultrawide monitor at the same time. After about a month of this, I swapped over to Hyprland and haven't looked back since.
While I never encountered any serious issues that prevented me from using my laptop when I first started, a few things didn't work properly all the time. In the past, I used to have a few issues getting screen sharing working, sometimes I couldn't launch a steam game. Since then, the experience has gotten to the point where I really don't notice any issues. Screen sharing works fine now, I can't remember the last time I couldn't get a steam game to launch. I don't even have issues with electron apps anymore. This is all while running on an Nvidia GPU.
I know there are still issues on things like accessibility, but from someone who doesn't have the time investment into Xorg, Wayland felt pretty good a few years ago, and now I really can't find anything to personally complain about with regards to it.
I started using sway seven years ago, and even then I had very few issues. Granted I use integrated Intel graphics and I mostly just want to arrange terminal emulators, but still, on that happy path, it hasn’t been a problem.
What software did you use? I have to use Google Meet, Microsoft Teams, Anydesk, and an onscreen keyboard. When I checked a couple of months ago, Anydesk wouldn't even launch. I have been dabbling with Wayland ever since it was made available on Arch Linux, but invariably have to go back to X.org after just a few hours on Wayland.
I finally moved to full-time Wayland around the time the OP published their original post, after a couple of decades of Xorg, and a number of failed attempts. Honestly, the biggest factor affecting my experience, subjectively, was ditching my 3090 and moving to amdgpu. I don't know if the situation with Nvidia drivers is much different now (I'm told it is), but my experience of Wayland on AMD has been stellar.
When I first moved over (i3->sway) I had a few scaling issues mostly due to Electron/Chromium and xwayland fallback, but for the last 12-13 months I've been rolling on solo Wayland with no fallback, and had zero regrets. The forcing function for this was switching over to niri[0], which if you haven't tried it, is an incredible ux.
I tried KDE Wayland a few times over the years but always had to switch back immediately because something I needed was broken. Then just a week or two ago I tried it again and didn't have to switch back. Everything finally worked, or could be made to work without too much effort. And bonus, sleep/wake works much better in Wayland than it ever did in Xorg.
That mostly KDE's fault, in my experience. For some reason it has always had great trouble getting there with Wayland whereas others got there a bit faster.
For me, it still isn't quite there for some hardware combinations.
I have been mostly-wayland for a while now and rarely have issues. I think the major pain point remaining is the fragmentation of the compositors, so that bugs (and features) depend strongly on your choice of desktop environment. I found a bug a couple years ago in sway on a thinkpad where holding down the physical mouse button (associated with the trackpoint device) and dragging on the clickpad would send button-up events every time I lifted my finger from the clickpad (even while the mouse button was held down). This turned out to be the responsibility of wlroots in a block of basically boilerplate code for translating libinput events. Meanwhile mutter was doing this correctly, so the wlroots developers pulled the fix from there (almost identical code). Some time later I switched to KDE and found that KWin also had the bug (fixed now after another bug report). The end result is that it's difficult to track down the source of unexpected behavior without intimate knowledge of your DE (whether the behavior was intended by the developers or not), and getting a bug fixed in one place is unlikely to fix it for everyone without a bunch of extra work. Like I said, I don't encounter a lot of these bugs, but there are a couple that I have been putting off tracking down because it feels like it will be a lot of work.
Wayland has been "nearly ready" for so long that it is easy to miss progress. I installed an arch desktop three months ago and setup kde with wayland, expecting that I would revert to xorg when something broke.
So far everything seems to work - although the machine has a strange glitch. Processes randomly die, but only if they have a render surface. Typically it happens to factorio or to the steam ui component, which are both incredibly stable.
I play Factorio quite a bit on Wayland and have never had a crash. I rarely use Steam but have a vague recollection of the overlay giving me a bad time. Might be something to try disabling if you haven't already.
> In the past, I felt a bit annoyed at people overselling Wayland when there were so many things still wrong with it on the fundamental level.
But the fundamentals of Wayland have barely changed at all. And yet now it seems fine? So can you really say that there were in the past many things wrong on fundamental level?
As explained in the article there have been significant additions to the Wayland protocols during the last 3 years, which have been necessary to fix the author's complaints.
These protocol changes appear to count as changes in the fundamentals of Wayland, because the older versions were incomplete, since features that were considered essential by the author were impossible to implement with the then-existing Wayland protocols.
In general, I think that there is no doubt that Wayland has been very badly designed in the beginning, so its fundamental features have been bad, because for many applications it has become usable only after many years of additions and changes, which have resulted in a quite different Wayland than in the limited vision of its creators.
Wayland still has fundamental choices with which I do not agree, so it is unlikely that I will ever switch to Wayland. For instance, I do not want a GUI application to touch anything outside the client area of a window. I want everything outside that area, e.g. window frames, decorations, titles, buttons, menus, etc., to be drawn by the window manager, so that they will always have an identical appearance and behavior, regardless which application is run in that window and regardless what the application does.
This is my knee-jerk reaction when people complain about wayland as well, and is often a correct reaction, but in this case the author really is talking about nontrivial wayland changes.
I think the author is saying that many things have changed since last post, the section "Upstream Wayland basically fixed most of the technical things I complained about" has a bunch of things that could be seen as "broken on the fundamental level" (from authors POV) in the past but today have been "fixed".
> My # 1 issue with wayland is it is Linux Specific, not protable.
Personally my #1 is just that stuff still don't work properly in a out-of-the-box Gnome+Wayland setup (on Arch). I still see weird things like a Firefox extension for making websites darker has a white line rendering through the pages when in use (probably something regarding aspect ratio?), some Electron apps like Obsidian sometimes have individual lines jittering up/down by 1-2 pixels (like it can't find the right/stable position), running nvidia-smi somehow introduces a 0.1 lag to seemingly my entire desktop, running it in a loop introduces that every run, and so on.
None of those issues happens with Xorg, and it just works without having set extra env vars for specific applications, or having to change the configuration just for Wayland to be used properly.
It seems to be less resource intensive, and smoother overall drawing, but all these issues make it kind of hard to start using daily over Xorg.
Yeah, you're probably right. I guess as I'm just an end-user who don't mind the internals that much, I'm just seeing how Xorg/Wayland work in the context of Gnome, so when I use Gnome+Xorg, everything works while using Gnome+Wayland leads to lots of stuff broken, so I associate the broken stuff with Wayland, although it could very well be the problem of how Gnome uses Wayland.
Although I'm not sure how Gnome affects how Firefox Extensions work, or how Electron applications render, I also don't know enough about the internals to say that's because of Gnome or Wayland.
its not even just arch linux. you can literally buy a PC from anyone who sells ubuntu 24.04 and you still cant properly install (and have them work out of the box) snap store items like shutter.
>Input is more complex to get working since Wayland applications expect Linux input model with udev, evdev and libinput.
>seatd and libseat provide support for non-systemd based systems. A basic port to OpenBSD/wscons is needed
So Wayland requires Linux specific items to be ported to BSD. Maybe FreeBSD did all that work themselves. Was that work accepted into upstream ? Based on how Linux works these days, I doubt it. So maybe each new Wayland Release will need to be patched for FreeBSD.
That patching is nothing new. It's pretty automated on FreeBSD. It has a ports system that does just that.
I don't think udev is ported though. Some linuxisms are, like dbus because several desktops need it. But FreeBSD has its own udev alternative called devd. Wayland is probably configured to just use that.
The compositor needs to talk to the hardware using kernel API and there's a bit of plumbing required, like for OpenGL / Vulkan apps to get a context under Wayland. Which isn't really "particularly" tied.
How does "lots" quantify, though? There are billions of desktop Windows users. There are tens of millions of desktop Linux users. I expect desktop BSD to go beyond the thousands, but does it reach the hundreds of thousands?
I've always felt like from a purely user perspective desktop BSD doesn't really distinguish itself from Linux. The software stack is essentially the same, and they're both FLOSS so that's not a reason to switch either. Maybe I'm wrong, but the Linux/BSD choice looks a lot less relevant than the Windows/Linux choice.
So if people use desktop BSD because it essentially gives them slightly fuzzier feelings, and they are essentially a rounding error in their user base, is it really fair to criticize Linux developers for not focusing on portability? You can only spend your time once, so do you use it to work on something benefiting your tens of millions of existing Linux users, or something benefiting your thousands of potential BSD users?
The question was if anyone uses BSD as a desktop and the answer is yes people do.
> You can only spend your time once, so do you use it to work on something benefiting your tens of millions of existing Linux users, or something benefiting your thousands of potential BSD users?
I couldn’t care less how the Wayland devs decided to prioritise their time. But it is worth pointing out that Wayland was architected from the ground up to be agnostic. That’s why it’s the polar opposite to the the “batteries included” design of X.
And as others have pointed out, Wayland is available for some BSD already.
Until it can actually be used as a graphical server like x, it is useless to me and I loathe every attempt to force it down my throat.
It feels like it was built as a replacement for only the majority happy path of what X was used for and all other uses were ignored when it was decided it would be adopted by distros and that really sucks.
Have you tried waypipe? Does it not fit your use case?
Last time I tested this, which was a few years ago, it worked just fine. But to be fair, this is not part of my workflow, just something I was testing out of curiosity.
If it doesn't do what you need for whatever reason, then I understand, but it just not true at all that the Wayland ecosystem has not been addressing these use cases.
I did try waypipe, but unfortunately there was both a significant memory cost and network overhead that does not exist with ssh -x.
To be fair I am using it in a very niche and limited way, but it still sucks to see it get pushed out in an ecosystem that is supposed to be all about maintaining support for niche systems.
Not to go off on a tangent, but over the last decade or so I feel like Windows has been better about making sure things keep working than modern distros have.
I want to avoid using Wayland for as long as possible. Is there a good way to donate to Xorg and preserving Xorg integration in software? How much would it take to change the GNOME people's mind about Xorg in GTK 5?
There's still no solution to the fact that everything by design must be mediated by the compositor. The article mentions protocols but they are far from standard. The assumption is basically just that everyone is going to use wlroots to make a compositor.
Gone are the days of 300 line of code apps like xbindkeys or maim that bind hotkeys or take screenshots and work everywhere. Instead it all must go through the compositor! So if you want to make your own accessibility app, you don't use xlib or xcb, instead you must modify your 30,000 line C code compositor to add a protocol for your app to work. And yes, there's supposed to be wlroots and standardized protocols, but not everyone implements them. So for instance KDE has their [own protocol](https://bbs.archlinux.org/viewtopic.php?id=298864) for screenshotting that's completely different than what wlroots uses.
Wayland is graphical communism designed to prevent a mythical class of software vulnerability. If someone has access to the point where they can read keystrokes on a Xorg system, realistically they already have arbitrary code execution. So yes, they couldn't just run their keylogger binary like they could on X, but there are 10 other things they could do to achieve the same effect. They could change the .xinitrc/other configs to load a modified compositor binary, or use some sort of LD_PRELOAD hook to intercept the "keyboard pressed" function on the compositor, as has been noted many times.
While I never encountered any serious issues that prevented me from using my laptop when I first started, a few things didn't work properly all the time. In the past, I used to have a few issues getting screen sharing working, sometimes I couldn't launch a steam game. Since then, the experience has gotten to the point where I really don't notice any issues. Screen sharing works fine now, I can't remember the last time I couldn't get a steam game to launch. I don't even have issues with electron apps anymore. This is all while running on an Nvidia GPU.
I know there are still issues on things like accessibility, but from someone who doesn't have the time investment into Xorg, Wayland felt pretty good a few years ago, and now I really can't find anything to personally complain about with regards to it.
What software did you use? I have to use Google Meet, Microsoft Teams, Anydesk, and an onscreen keyboard. When I checked a couple of months ago, Anydesk wouldn't even launch. I have been dabbling with Wayland ever since it was made available on Arch Linux, but invariably have to go back to X.org after just a few hours on Wayland.
When I first moved over (i3->sway) I had a few scaling issues mostly due to Electron/Chromium and xwayland fallback, but for the last 12-13 months I've been rolling on solo Wayland with no fallback, and had zero regrets. The forcing function for this was switching over to niri[0], which if you haven't tried it, is an incredible ux.
[0]: https://github.com/YaLTeR/niri/
For me, it still isn't quite there for some hardware combinations.
So far everything seems to work - although the machine has a strange glitch. Processes randomly die, but only if they have a render surface. Typically it happens to factorio or to the steam ui component, which are both incredibly stable.
Does the kernel log not show anything? Or maybe the steam log?
I am sure that somewhere there's a hint of what's going on.
Need to use pipe wire for screen sharing
Chrome drag and drop have huge performance hits
Multi monitor setup is bad
But the fundamentals of Wayland have barely changed at all. And yet now it seems fine? So can you really say that there were in the past many things wrong on fundamental level?
These protocol changes appear to count as changes in the fundamentals of Wayland, because the older versions were incomplete, since features that were considered essential by the author were impossible to implement with the then-existing Wayland protocols.
In general, I think that there is no doubt that Wayland has been very badly designed in the beginning, so its fundamental features have been bad, because for many applications it has become usable only after many years of additions and changes, which have resulted in a quite different Wayland than in the limited vision of its creators.
Wayland still has fundamental choices with which I do not agree, so it is unlikely that I will ever switch to Wayland. For instance, I do not want a GUI application to touch anything outside the client area of a window. I want everything outside that area, e.g. window frames, decorations, titles, buttons, menus, etc., to be drawn by the window manager, so that they will always have an identical appearance and behavior, regardless which application is run in that window and regardless what the application does.
I am hoping the *BSDs get together and keep Xorg maintained instead of having to port Linux crazyness into their systems.
Personally my #1 is just that stuff still don't work properly in a out-of-the-box Gnome+Wayland setup (on Arch). I still see weird things like a Firefox extension for making websites darker has a white line rendering through the pages when in use (probably something regarding aspect ratio?), some Electron apps like Obsidian sometimes have individual lines jittering up/down by 1-2 pixels (like it can't find the right/stable position), running nvidia-smi somehow introduces a 0.1 lag to seemingly my entire desktop, running it in a loop introduces that every run, and so on.
None of those issues happens with Xorg, and it just works without having set extra env vars for specific applications, or having to change the configuration just for Wayland to be used properly.
It seems to be less resource intensive, and smoother overall drawing, but all these issues make it kind of hard to start using daily over Xorg.
Although I'm not sure how Gnome affects how Firefox Extensions work, or how Electron applications render, I also don't know enough about the internals to say that's because of Gnome or Wayland.
Of course it's portable. Your complaint that it hasn't been ported a lot of places may be well-placed, but it's a different complaint.
> I am hoping the *BSDs get together and keep Xorg maintained instead of having to port Linux crazyness into their systems.
"Foo is crazy and isn't ported – I therefore hope that people don't port crazy foo". What?
https://xenocara.org/Wayland_on_OpenBSD.html
>Input is more complex to get working since Wayland applications expect Linux input model with udev, evdev and libinput.
>seatd and libseat provide support for non-systemd based systems. A basic port to OpenBSD/wscons is needed
So Wayland requires Linux specific items to be ported to BSD. Maybe FreeBSD did all that work themselves. Was that work accepted into upstream ? Based on how Linux works these days, I doubt it. So maybe each new Wayland Release will need to be patched for FreeBSD.
I don't think udev is ported though. Some linuxisms are, like dbus because several desktops need it. But FreeBSD has its own udev alternative called devd. Wayland is probably configured to just use that.
Its been ported to FreeBSD.
Would it be more true to say Wayland on *BSDs lags Wayland on Linux? Its not tied to Linux the way systemd is, right?
I've always felt like from a purely user perspective desktop BSD doesn't really distinguish itself from Linux. The software stack is essentially the same, and they're both FLOSS so that's not a reason to switch either. Maybe I'm wrong, but the Linux/BSD choice looks a lot less relevant than the Windows/Linux choice.
So if people use desktop BSD because it essentially gives them slightly fuzzier feelings, and they are essentially a rounding error in their user base, is it really fair to criticize Linux developers for not focusing on portability? You can only spend your time once, so do you use it to work on something benefiting your tens of millions of existing Linux users, or something benefiting your thousands of potential BSD users?
The question was if anyone uses BSD as a desktop and the answer is yes people do.
> You can only spend your time once, so do you use it to work on something benefiting your tens of millions of existing Linux users, or something benefiting your thousands of potential BSD users?
I couldn’t care less how the Wayland devs decided to prioritise their time. But it is worth pointing out that Wayland was architected from the ground up to be agnostic. That’s why it’s the polar opposite to the the “batteries included” design of X.
And as others have pointed out, Wayland is available for some BSD already.
It feels like it was built as a replacement for only the majority happy path of what X was used for and all other uses were ignored when it was decided it would be adopted by distros and that really sucks.
Last time I tested this, which was a few years ago, it worked just fine. But to be fair, this is not part of my workflow, just something I was testing out of curiosity.
If it doesn't do what you need for whatever reason, then I understand, but it just not true at all that the Wayland ecosystem has not been addressing these use cases.
To be fair I am using it in a very niche and limited way, but it still sucks to see it get pushed out in an ecosystem that is supposed to be all about maintaining support for niche systems.
Not to go off on a tangent, but over the last decade or so I feel like Windows has been better about making sure things keep working than modern distros have.
Why?
Other than that, it all just works!
Gone are the days of 300 line of code apps like xbindkeys or maim that bind hotkeys or take screenshots and work everywhere. Instead it all must go through the compositor! So if you want to make your own accessibility app, you don't use xlib or xcb, instead you must modify your 30,000 line C code compositor to add a protocol for your app to work. And yes, there's supposed to be wlroots and standardized protocols, but not everyone implements them. So for instance KDE has their [own protocol](https://bbs.archlinux.org/viewtopic.php?id=298864) for screenshotting that's completely different than what wlroots uses.
Wayland is graphical communism designed to prevent a mythical class of software vulnerability. If someone has access to the point where they can read keystrokes on a Xorg system, realistically they already have arbitrary code execution. So yes, they couldn't just run their keylogger binary like they could on X, but there are 10 other things they could do to achieve the same effect. They could change the .xinitrc/other configs to load a modified compositor binary, or use some sort of LD_PRELOAD hook to intercept the "keyboard pressed" function on the compositor, as has been noted many times.