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.
sevensor 29 days ago [-]
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.
qart 29 days ago [-]
> Screen sharing works fine now
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.
paranoidxprod 29 days ago [-]
Zoom, Teams and Discord all work for me. I have used Anydesk to remote into other machines, but haven't tried sharing through it myself.
chmod775 29 days ago [-]
All of these, just like browsers, probably XDG Desktop Portal for capturing, so you've got to have that set up.
Siilwyn 29 days ago [-]
Can confirm Google meat & ms teams work.
NullPrefix 29 days ago [-]
hyprland website is unusable on slower computers. Can't imagine that the WM itself would be any better
Vilian 28 days ago [-]
It's one of the faster and lightweight compositor out there, he probably know how to write c++ and not or don't care with web and javascript
29 days ago [-]
boomskats 29 days ago [-]
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.
darthrupert 28 days ago [-]
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.
topaz0 29 days ago [-]
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.
amoss 29 days ago [-]
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.
Volundr 29 days ago [-]
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.
amoss 28 days ago [-]
thanks, i'll try that Nd see if it helps.
Levitating 29 days ago [-]
> Processes randomly die
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.
amoss 29 days ago [-]
Nothing in the kernel log and the steam log shows a trace, but no debug symbols, only raw addresses.
v3ss0n 29 days ago [-]
Using and embracing Wayland, still Many things broken.
Need to use pipe wire for screen sharing
Chrome drag and drop have huge performance hits
Multi monitor setup is bad
zokier 29 days ago [-]
> 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?
adrian_b 29 days ago [-]
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.
topaz0 29 days ago [-]
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.
diggan 29 days ago [-]
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".
sevensor 29 days ago [-]
I want to take a second to appreciate how classy this post is. Doubling down on negative opinions is easier and all too common.
jmclnx 29 days ago [-]
My # 1 issue with wayland is it is Linux Specific, not protable.
I am hoping the *BSDs get together and keep Xorg maintained instead of having to port Linux crazyness into their systems.
diggan 29 days ago [-]
> 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.
akimbostrawman 29 days ago [-]
I know this doesn't help but those seem like GNOME issues not Wayland protocol issues. Using Nvidia also probably doesn't improve the odds.
diggan 29 days ago [-]
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.
palata 29 days ago [-]
Agreed. I am using Sway; it just works (tm).
Wheaties466 29 days ago [-]
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.
gspr 29 days ago [-]
> My # 1 issue with wayland is it is Linux Specific, not protable.
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?
klooney 29 days ago [-]
FreeBSD already ported it, I don't know a about the rest. Why do you think it's particularly tied to Linux?
jmclnx 29 days ago [-]
Because to get it working, something like udev, edev, libinput needs to be brought over, polluting a clean system. Some quotes from:
>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.
wkat4242 29 days ago [-]
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.
ahartmetz 29 days ago [-]
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.
Would it be more true to say Wayland on *BSDs lags Wayland on Linux? Its not tied to Linux the way systemd is, right?
phoronixrly 29 days ago [-]
Did I hear Windows subsystem for Wayland?
wkat4242 29 days ago [-]
I'm on FreeBSD and they have Wayland. I'm not using it yet, but it does have it and support is being improved. It's not as stable yet as X11 though.
emersion 29 days ago [-]
The Wayland library has upstream support for FreeBSD and OpenBSD. Some compositors also have upstream support for these.
tyho 29 days ago [-]
Does anyone really use an X GUI on BSD?
hnlmorg 29 days ago [-]
Yes. Lots of people do. There are even BSD OSs that primarily target desktop use, such as DragonflyBSD.
crote 29 days ago [-]
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?
hnlmorg 29 days ago [-]
Does it matter?
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.
wkat4242 29 days ago [-]
Oh yes. It's my daily driver. KDE on FreeBSD (with X11 stack still)
pama 29 days ago [-]
It is good to occasionaly display windows from a remote linux onto a macbook client. I wouldnt say I use it regularly but it certainly helps.
badgersnake 29 days ago [-]
I use sway, so no.
devmor 29 days ago [-]
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.
emmp 29 days ago [-]
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.
devmor 29 days ago [-]
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.
sevensor 29 days ago [-]
You’ve been able to run an x server within sway from very early days, it’s just not managing windows any more. X11 forwarding over ssh still works.
aragilar 28 days ago [-]
For now. Won't work for GTK at the next major release.
nesarkvechnep 29 days ago [-]
I've been happily running Sway on FreeBSD for two years. It runs and looks great. No blurry fonts, no tearing.
costco 28 days ago [-]
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?
kennysoona 27 days ago [-]
> I want to avoid using Wayland for as long as possible.
I have been using Sway since end of 2023. The only thing that I can't get is sharing a window in videoconf calls. I have to share the whole screen.
Other than that, it all just works!
bean-weevil 29 days ago [-]
I also use sway. I'm considering switching to hyprland because it supports this.
29 days ago [-]
costco 28 days ago [-]
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.
thwg 29 days ago [-]
It is so bad that it is not worth assessing in the first place.
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.