Reassessing Wayland
dudemanguy.github.io
dudemanguy.github.io
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.
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.