Are We Wayland Yet?
arewewaylandyet.com
arewewaylandyet.com
At this point my systems are going to be pure AMD until status quo changes. I begrudgingly used Nvidia while they were the better of 2 proprietary blob options but now that AMD GPUs work out of the box with no hassle (for the ones I have tried at-least) and are competitive on performance for what I do (consumer workloads/gaming) then there is no contest.
Right now I'm daily driving Wayland + Sway on Arch and it's been mostly good. Only issues I have ran into have been weirdness in the whole Alsa + Pipewire + etc stack which is hairy AF. Configuring Electron things to use Ozone auto detection makes them run native rather than via XWayland which is nice too.
How did you manage to set this up? Some environment variable? The best I've managed to do was to change the applications .desktop file to include Ozone wayland parameters.
At least the last time I tried, between Arch repos and AUR, I had some versions of Electron that'd pick it up, and some that wouldn't.
My first PC I built and used with Linux used an ATI Radeon graphics card (now owned by AMD). It had such poor Linux support that I swore I'd never buy ATI again. Nvidia's drivers were way better in those days.
Additionally, I have set up Nvidia's gamestream so I can keep my Windows devices tucked away in a closet and that allows me to game on the go -- and not have to directly interface with my Windows machine aside for gaming related stuff. So most games I stream to either my Apple TV, iPhone or Dell XPS running Arch (when I want to use a mouse+keyboard).
My Wireguard setup combined with Moonlight allows me to stream remotely, too! When I am visiting in-laws a few hundred miles away it works flawlessly.
It's super nice to be able to game remotely :)
However, if you are also using ungoogled Chromium from Arch, you are doomed to use Pipewire.
For example Ubuntu switched to using it by default a while back. Unfortunately since Wayland prevents the usual screen sharing in many popular communications applications from working I usually have to go back to X in order to do any real work remotely.
Combine that with some significant bugs that seem to happen in recent versions of Ubuntu/X but not Ubuntu/Wayland and now I have no fully working GUI on my Ubuntu machine because both options now have game-stopping problems.
I do understand that there are good reasons for Wayland wanting to do what it's doing and breaking the old-fashioned screen sharing is a consequence of those. I understand that applications should be updated and other packages should be used and so on. I hope that these issues can be fixed sooner rather than later and we can all benefit from the technical advantages of Wayland.
But if I'm in a conference call with important people about an important subject you can count the number of excuses I care about on the fingers of no hands. Wayland won't be ready for "normal" users until essential functionality works out of the box.
Screen-sharing is working out of the box for me on both gnome and wlroots. File a bug to your distro maintainers if it doesn't.
I do appreciate your response but ironically you're also demonstrating exactly the point I was trying to make. As long as I have to worry about installing x-y-z-beta (but make sure it's the one from two weeks ago because last week's had a regression) to make essential basic functionality work we aren't really talking about a serious offering for normal users.
In reality like almost every other Ubuntu user I've talked to in real life about this I just switch back to X if I need to screen share. And if that stops working I'll switch from Ubuntu to something that does. Like building my own PC with micro-optimised component choices, tweaking Linux system software was interesting for a while and sometimes got great results, but life's too short to keep doing that forever. Now I just want something that does its job.
Of course it does. My argument is that for many users Wayland's time has not yet come. The kind of very noticeable issues some of us have mentioned in this discussion need to be fixed so things work normally as standard before that will really happen.
Wayland either lingers in the background indefinitely, or it gets “pushed” in a good-enough state, “forcing” misbehaving apps to fix themselves.
OSX and Windows can just say “we are using W from version V” and you loose business if you don’t update. There is only popularity as a incentive on a FOSS platform.
The problem with this argument is that it's almost certainly true. If you are a fan of Linux and hoping for it to gain market share and by extension grow the ecosystem for everyone that is not good news.
It doesn't matter if "most linux users" contribute or not. Only a minority report bugs, and an even smaller minority fix bugs.
There is an old saying that if you want something done right... well, let's not be cynical. Let's just be grateful that we have the opportunity to do things right!
Overall, this is one of the big architectural things that is horribly wrong with Wayland. Not offering a "batteries-included" path for everyone still using legacy systems is going to destroy adoption rates once you start looking outside the hobbyist crowd and towards enterprise/LTS markets. I get why you'd want to keep these components separate, but there's really no point now. Nobody is using this code as a module, they're simply re-implementing the same thing into different desktops over-and-over again. It's one of those rare moments where Xorg's monolithic codebase isn't a detriment, for once.
It's really only the larger DEs that will want to roll their own compositor like GNOME/mutter. Wayland allows them to do that in a feasible way, but it doesn't force them to because they can use something like wlroots.
>the onus is now on each individual desktop environment to provide it's own implementation of screensharing
wlroots-based DEs can simply use wlroots' screen-sharing implementation for example.
The wayland equivalent to the smaller DEs that relied on Xorg to reduce their complexity and maintenance is just smaller DEs using wlroots or similar.
The larger DEs like Gnome and KDE will have no problem bearing the onus of implementing wayland themselves. I've had it screen sharing working perfectly on gnome for the better part of a year already.
My example of a project doing this well is PipeWire. They looked at the Linux audio scene at the time (arguably worse than xorg on many accounts) and created a replacement that both supported old paradigms while simultaneously promoting lower-latency, higher-quality ways to connect. Wayland should have taken the same approach: it's never going to kill it's past, so it may as well adopt it. If I could use Wayland as a compositor while keeping x11 as my window server, I would. I wouldn't get the "full security" of Wayland, but I'd be onboard with their project if the maintainers weren't so allergic to user choice.
I don’t see how your supposed compositor/window server hybrid would solve any of the problem of the past - what would even be the task of wayland there? It would be what kde plasma does with its compositor.
But I don't think that's Wayland's fault - it's up to those apps to upgrade their UI libraries (which might be a monumental task, I'm not sure).
I know GIMP is working towards GTK3 and hopefully that fixes the issue.
As for Calibre. It uses PyQT. Does anyone know if PyQT supports fractional scaling now? And what it would take for something like Calibre to upgrade to a newer PyQT version?
Actually, it is Wayland's fault[0], and arguably Xorg is able to handle it better[1].
Basically, the protocol doesn't currently support sending a fraction as the scale to the application, so whenever you've got displays with DPIs that are not integer multiples of one another, the compositor will scale down on at least one of those displays, causing blur. In Xorg, it is normal for applications to simply detect the DPI of the display they're on and render accordingly. In either case, it requires support from the graphical framework used by the application (eg, Qt applications seem to automatically handle this on Xorg).
I would quite like to replace one of my monitors in a multi-monitor setup with a HiDPI one, but lack of support for this is what's holding me back. I'd be happy enough if Firefox just added support to Xorg for DPI detection[2], though if Wayland gets this working first, I'll probably switch over to that (I've gone back and forth between Xorg/xmonad and Wayland/sway, and I don't really see any other blockers for me).
[0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...
[1] https://www.reddit.com/r/kde/comments/lficfe/wayland_fractio...
BTW, as a fellow long-time xmonad user who never managed to get fully used to the i3/sway tiling model I've been very happy so far switching to Qtile on my X11 machine. Took a couple of hours to replicate my decade-of-custom-crust Xmonad setup and another couple to add some new nice stuff I either wasn't able to or never bothered with (scratchpad/dropdowns for my top 5 frequently used apps like chat,pavucontrol,music,dashboards has already been a productivity improvement).
It seems to be on good track to work well in native Wayland mode as well, meaning we can have the same WM on both :)
The main applications I use are Firefox and some terminal emulator, so I would be happy as long as I can get both of those working using fractional scaling on either of Wayland/Xorg (without downscale blurring).
It doesn't work in Wayland due to limitations in the protocol and it doesn't work in Xorg simply because Firefox haven't implemented it there (and they seem to have closed the issue as WONTFIX, telling people to use Wayland instead, which has this issue that GGP raised).
It does work specifically in Xorg in Qt applications, though I don't actively use any of those.
IIRC the only thing I eventually did to make things work was setting env vars
MOZ_ENABLE_WAYLAND=1
MOZ_WAYLAND_USE_VAAPI=1
As for terminals: foot has some weird behavior with font sizes[0] but kitty and alacritty have not had surprises here so far (though I didn't try alacritty in multi-DPI situation yet)
> An integer is recommended, but fractional values are also supported. If a fractional value are specified, be warned that it is not possible to faithfully represent the contents of your windows - they will be rendered at the next highest integer scale factor and downscaled.
I've just tried it again myself and can observe the downscaling. I can provide screenshots later demonstrating the scaling artifacts if anyone is really interested.
[0] I configure my systems to perform crisper font rendering using `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, along with some extra fontconfig options. This results in glyphs being aligned with actual pixel boundaries, reducing the need for antialias blurring.
[1] https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc60...
Even so, downscaling (as opposed to upscaling which is what I think happens on Xwayland) while not "100%" should still not manifest as blurriness, though?
Okay, so for reference, here's how I normally see text rendered (I opt in to FreeType's v35 TTF interpreter, which hints (aligns) to full pixels rather than subpixels [0], which to me produces much clearer text than the now-default v40):
FTv35, Sway 1.00x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...
Here's how it looks again using the v35 interpreter, but scaled up to 1.25x, first using Sway [3] and second using Firefox (so in both cases the content text should be more-or-less the same size):
FTv35, Sway 1.00x, Firefox 1.25x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...
FTv35, Sway 1.25x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...
Using the v40 interpreter, the differences are harder to notice, but this is because the text has already been blurred due to extra horizontal antialiasing [1] [2], so blurring it a second time only makes the artifacts slightly worse instead of introducing new ones:
FTv40, Sway 1.00x, Firefox 1.25x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...
FTv40, Sway 1.25x, Firefox 1.00x: https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac...
Even in the v40 images, the Firefox scaling looks better to me than the sway scaling. Additionally, the border around the text area is noticably clearer, since Firefox has intentionally drawn it to align with the pixel grid, but when it gets scaled by Sway, the correspondence between Firefox's pixel grid and the device pixel grid is lost.
Also note that all of these images have a sample of text in the bottom left corner that has been upscaled 800% with no/nearest interpolation, so the individual device pixels can be seen clearly.
If someone wants to download all of these images in one go:
$ git clone https://gist.github.com/Maxdamantus/2ba942eb20a58f0ec0708cac7db92a9a
> Even so, downscaling (as opposed to upscaling which is what I think happens on Xwayland) while not "100%" should still not manifest as blurriness, though?
Yes. The downscale is done using "linear" interpolation (which averages/blurs adjacent pixels together—this is demonstrated in my v35 images by the grey vertical lines in text). sway also supposedly supports "nearest" interpolation, but this doesn't seem to work when I configure it, maybe it only does it when upscaling, not downscaling (I expect this would look worse anyway).
[0] https://freetype.org/freetype2/docs/hinting/subpixel-hinting...
[1] In fact, as I understand it, "super sample anti-aliasing" is when a graphic is rasterised to a larger image and then scaled down linearly, and this is what video game graphics attempt to approximate with "multisample anti-aliasing", so "antialiasing" really does imply "blurring"
[2] I feel I should also point out that this might make it hard to properly see the difference in clarity between the v35 images and v40 images for people that are already using simulated fractional scaling. Preferably the pixels in these images should be rendered directly to the viewer's device pixels.
[3] As discussed, the upscale to 1.25x in sway actually involves rendering at 2.00x and then scaling down by 0.625x, because 2*0.625 = 1.25
I have to zoom in quite a bit and look closely to tell the difference and can still barely make out which one is better. Comparing with my setup (FF1.0/sway1.25) it looks different to both but perhaps that's due to different fonts or resolution. Anecdotally the performance here is better than your sway but worse than your FF. At this point it's similar to the difference between high and medium bitrate for an MP3 though - I might make out the difference if I focus but in no way does the lesser version affect my experience otherwise.
I guess this is semantics but I still wouldn't call it "blur", maybe "suboptimal downscaling".
That being said, I understand things like this affects us differently and that it's a valid issue for you and probably others - just like suboptimal audio encoding ruins the music listening experience for some.
I use scaling x2 (on 4k). Everything is crisp, as long as its Wayland. There's a bunch of env variables I have to set though, including for Qt and Gtk IIRC. But I just export them in my Sway config.
There is fractional scaling though under Wayland which works fine for Wayland applications.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...
It turns out there has been some activity recently, but this seems to all be in the form of draft PRs:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
You are correct in saying that it requires support from the client. This is even the case for integer scaling, which is why it's unfortunate that there's a protocol and clients that are specifically designed around integer scaling without addressing fractional scaling.
The OSX solution is the only one that will avoid insane complexity at all levels (protocol, compositor, and client), and as demonstrated by OSX, can work fine in a mixed-DPI environment.
Try running a web browser with fractional scaling, open up a JS console, and look at the values for `devicePixelRatio` and `innerWidth`. You'll probably see that the former is an integer (particularly, the ceiling of your configured scale, eg, 2), and the latter is wider than the actual number of device pixels. This means the web browser is rasterising to a larger size and then being downscaled.
Unless the rasterisation size is an integer multiple of the final pixel size (which it's not), there will be unavoidable "pixel-snapping artifacts". This is basically the whole premise behind vector graphics. You wouldn't use a bitmap font that's been scaled down to the right size, but this is effectively what happens when viewing text on Wayland with a non-integer scale.
I'd appreciate a checkpoint for 'application-managed fractional scaling', i.e. a protocol extension that says "oi, Firefox, the screen you're on wants you to render at 96*1.5=144dpi". There are issues and discussions ongoing regarding this.
Everything else Wayland, including app-managed integer scaling, is working fab here. (Pop / Gnome since 40 )
Yikes.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
The alternatives of alternatives madness with system components not working with each other is why many don't bother supporting users on all 'supported' Linux distros altogether and instead target Windows and macOS. It isn't the early days of the Linux Desktop where people are first discovering that 'Linux' exists; it's been over 20+ years and the same chaos in the Linux Desktop is still present.
Wayland is another thing to test against, for these poor app developers (especially Electron app / core developers) discovering issues like these two [0][1] which are still happening on their systems.
It is totally impossible to support all these Linux users 100% of the time unlike the other two OSes (macOS and Windows), no matter the many infinite desktop configurations they may have. That is even before I mentioned drivers; especially anything NVIDIA.
Do your own research. Wayland is an improvement for web browsing and text editing, but I've found it unusable for anything outside of extremely light, limited workloads. YMMV.
Definitely less Jane resizing windows with Wayland.
KDE is much better at displaying GTK apps than Gnome is at Qt apps.
Apart from lots of display switching and scaling causing quirks everywhere.
Having read some of the threads on the freedesktop wayland gitlab repo about push to talk, I'm not confident push to talk or any other system for applications to register a global hotkey is something they'll deliver any time soon (if ever).
That entry is both mislabelled and way too short. Inkscape is there for illustrating / vectors, but image editing has other apps.
But I run xorg for this reason.
Here are my biggest problems:
* On X11, after waking from sleep, fonts are sometimes garbled. This is easily fixed by restarting GNOME. I never have to do this with Wayland.
* On X11, I always have to manually rearrange my monitors every time I plug them in, because some part of the stack doesn't know how to remember them. They work perfectly on Wayland.
* On Wayland, GNOME's Night Light feature does not work. Night Light tints things red in the evening to help me sleep.
* On Wayland, some apps misbehave in strange ways. Electron-based apps are sometimes slow to react to input, but updates have been fixing this. Also, Calibre's Ebook Viewer perpetually hangs. I have no idea why.
Fortunately, switching between X11 and Wayland is pretty easy--just a log out and then back in after specifying which one I want.
Gaming is different. It rarely works on Wayland. Much better on X11. But I don't game very much, so this is not based on a really wide selection.
But for someone like me, all the software I use is completely fungible except for the browser and DE, and my recent switch to Wayland could've used precisely this dashboard.
The real complaint here is that the dashboard is inaccurate, at the very least by omission. The checkbox elides the level of stability implied by "support", for software as central as Chrome
I would love to hear how you can possibly know that.
> it's not our fault you decided that you want to use fluxbox on gentoo
If you like monocultures and arbitrary restrictions, maybe try Darwin?
Same as wayland.
> If wayland results in a monoculture of desktop environments, that will be a regression.
It isn't, because you have everything that's ported to Wayland _and_ everything that's ported to X11. So it's the opposite of a monoculture.
> Same as wayland.
No, because Wayland puts everything on the compositor. X11 let me run the same screenshot tool on GNOME, KDE, and dwm. In wayland, the only way to support GNOME, KDE, and sway is to add multiple backends. In X11, window managers and compositors were interchangeable and orthogonal; in Wayland, the "window manager" is subsumed into the compositor (now mandatory), which is the display server. I really like keynav. AFAICT, implementing an equivalent in Wayland requires integration into each compositor. There's still a monolith, but it got moved up the stack to a place where it prevents piecemeal environments.
Per [0], as of June 2022, Wayland is at 24.6% versus X11 at 67.7%. It's not a random sample, but it suggests that Wayland is not yet what most people are using. Wayland's usage suddenly doubled in April 2022, presumably due to Ubuntu 22.04.
So much to do there though: 64bits clean, not crashing without dbus, not bash but sh scripts, removal of the 32bits legacy code, pure and simple ELF64 application (static libstdc++ and libgcc) libdl-ing everything from the system (to maximize distro compatibility, but then a fork of libstdc++ is needed: usual c++ toxicity), wayland->x11 fallback, vulkan->gl->cpu fallback (that said the 64bits steam client is libcef from gogol, then certainly with all those fallbacks already there).
It's a testament to desktop Linux's improvement that I haven't felt that way in a decade, and have a much higher stability bar than I do for Windows or my limited Mac usage. But having my browser processes freeze once a week is well below the standards I've come to enjoy, and I'm wondering if I should just switch back to X and deal with the minor graphics hiccups.
No idea how Wayland would affect a Samba share, but like you I just wanted it to work so that was that for now.