In addition to all these numbers, AMD also finally fixed the GPU reset bug with 6800 cards[1], which is huge for those of us running GPU passthrough to a VM as a BACO workaround kernel patch is no longer needed. Possibly going to be more stable on Linux as well as the card can recover itself from crashes. Big Navi also has its driver upstreamed in current 5.9 kernel so no more first day disaster like Navi.
(Meanwhile Nvidia also removed the "error 43" limitation when it detected the card is being run in a VM, so VFIO scene is getting a lot more interesting in this generation.)
I think that, for my use case, it would be a good combo to put both an Nvidia card and an AMD card in the same Linux machine, using the AMD one on Linux and spinning up VM guests using the Nvidia card for Windows gaming or for ML work. This way I can use Wayland (especially the Sway window manager) for my development workflow while being able to use CUDA and stuff.
Wayland still not ready for daily use. Over last few years I tried it several times with Kubuntu and KDE Neon and every time stuck with issues latest of which was impossibility to make Virt-viewer client work properly on 85Hz.
Also some issues with hardware acceleration in Firefox, glitches in IDEA IDEs, etc. Also 3 monitors configuration sometimes end up messed up...
That's almost as much an over-generalization as saying "PC is not ready for daily use". Wayland is a protocol (or even a family of protocols), kwin is one specific compositor which implements it (and the implementation is still far from being complete from what I hear). I've been using a different compositor for about a year now, and I don't miss Xorg one bit.
Sucks to hear that I've been exclusively using a compositor that wasn't ready for the last 8 months. Sway is the best desktop computing experience I've ever had, "ready" or not.
No proper screen sharing through any mainstream videoconference application is a killer for work. (0)
chromium doesn't support wayland yet, so it is blurry in HiDPI displays with scaling (chromium-dev does, but it has so many bugs it isn't even funny). As a consequence, all electron apps end up blurry... of which there are many.
Same applies to all apps that don't support Wayland yet. For example, I spend 90% of my time using Emacs, and it is blurry on Sway if I enable HiDPI scaling.
---
So sure. If you don't have a "modern" HiDPI monitor, and if you don't need to screen share often, and if you don't need to use chromium for work, or any App that doesn't support wayland yet, like all electron apps, Emacs, etc., or your work involves ML, or you want to game, or have an nvidia graphics card, which sway does not want to support (as opposed to gnome and kde), and you don't want to buy two GFX cards, or if you have to do screen sharing, or probably another dozen other things that most users need to do occasioanlly, or even every day. Then, and only then, Sway might be for you.
But you can also use i3, where all this stuff just works.
---
(0) I've seen people creating virtual webcams using OBS studio to capture their screen and share it as their "webcam" in videoconferences, but no mainstream software really supports this "as screen sharing", so the quality is quite bad, in a meeting with 10 people everyone needs to pick the webcam because the apps don't support this huge hack, etc.
FWIW, the thing about HiDPI being blurry is partly design difference between X11 and Wayland, and partly design decision on sway part (to not support this scenario). Having X11 and Wayland applications in HiDPI means having to handle two DPI in a single screen (e.g. sway have to render Xwayland window at 1x, while other windows at 2x).
This can be quite tricky since Xwayland's DPI may not always equal to `display DPI * Wayland scale` and while DPI settings in X is global, scale settings in Wayland is per-output. GNOME for instance has HiDPI working for both Xwayland and Wayland windows but with lots of magic going on with the framebuffer. HiDPI for X window in Plasma is still in the works AFAIK.
All the things you mentioned are already fixed and most have had reasonable workarounds for a while. Some are still working their way through the distros so it's still a work in progress in places but it also has unique upsides from the Xorg experience.
> All the things you mentioned are already fixed and most have had reasonable workarounds for a while. [...] Some are still working their way through the distros [...]
Can you back this up ?
Because I can back this up that this is not the case.
* Neither Chromium nor Firefox properly support wayland yet and have a lot of bugs. Fedora ships a patched version of Firefox to workaround some of these issues, so does arch, but none of this is properly fixed. Chromium-dev + patches does not handle multiple displays with different resolution (text is in the wrong position, toolboxes are wrong), it is not able to share a full screen (shows up as black), etc.
* Emacs does not support Wayland yet. Some users have some patches no enable GTK3 wayland support, but these work badly with Wayland/Sway, not properly recognizing input devices (e.g. Delete key recognized as Backspace is the classic bug for this). Users using these have to remap their keyboards every time they start emacs.
* Point us to one Electron app with Wayland support please. Just one. Go ahead. I'll go sit down, and wait, in case you need to wait for any to be released, maybe next year, or the year after that. Whatever the "Year of Wayland" in the Linux desktop will be.
* Can you share a screen shot of the Zoom or Webex videoconferencing software (the native packages) on Sway sharing monitors ? If not, don't worry. Can you share a screen shot of using their crappy web versions through any official browser release (unpatched) sharing full monitors through screen sharing?
- I've been using Firefox as Wayland native for a long time now. It works fine, certainly better than in X. I use the version as shipped by Ubuntu with no changes. Initially there were some bugs but haven't had any that are Wayland specific in a while. Chrome has recently enabled Wayland support in the release builds. I've only briefly tried it in that mode so I don't know what bugs it may have.
- Emacs is X-only because of the way it's built, that will take a while to fix. But XWayland works fine. The blurryness with HiDPI is fixed by a workaround in XWayland. I haven't used it myself because I don't use either emacs or fractional scaling but the solution exists.
- Electron is now getting Wayland support with the new versions but it's not needed to use those apps. I use Microsoft Teams daily in a HiDPI screen even. It works fine under XWayland and even has a setting to change the size of the interface if wanted. Everything but screen sharing works.
- Screen sharing with pipewire exists and works in both Firefox and Chrome, it's still going through the channels to be available in distributions. The first workaround is sharing a tab instead of a screen in Chrome. That has always worked fine and I've used it extensively for presentations. The full workaround is that Chrome under XWayland is also able to share any other XWayland window so it's possible to create a fake output, connect to it using a VNC app running under X and share that app. Complete hack until we get proper pipewire support from Electron apps adopting newer Chromium. Don't know about Zoom and Webex but if those support X sharing the same hack works and if they're native apps they also need a pipewire patch.
If you're happy with your Xorg session then by all means stick with it. Quips about year of the Wayland desktop are actually quite appropriate as they're the same as the complaints about year of the Linux Desktop. For me the year of the Linux Desktop was over 20 years ago, and I've been taking advantage of it ever since. The year of the Wayland Desktop for me was this year, as even after dealing with the rough spots I've gotten quite a bit of value from the transition. If you use different apps or have different requirements you may want to wait more, no one is forcing you to switch. Complaining online that your use cases aren't solved to your satisfaction in open-source projects is a bit much in my opinion.
Genuine question, from a users perspective what are they?
The couple times I've used it, I ended up going back to xorg because it turned out something didn't work (intel integrated graphics) right. Its sorta become a habit now.
HiDPI displays is what I see mentioned the most. But when you then ask if fractional scaling works on Wayland, the answer is "yes, but it doesn't work for any app you actually use".
If all you want to do is download a "demo" terminal, and put it in a HiDPI display, and enable fractional scaling, to show it to your friends, then yes, this works.
If you want to get some work done on any app (a text editor, web browser, ...). Then its worse than Xorg at the moment.
Totally unrelated, but I refuse to buy an HDPI monitor until someone makes one at a resolution that can use integer scaling. Fractional scaling will _never_ look good. Even Apple, who controls their entire stack, doesn't like fractional scaling and exclusively makes monitors and displays that support 2X scaling. Everyone looking for good fractional scaling support is going to be looking for a very long time, no matter what compositor they use.
Apple does fractional scaling in all their laptops. And the reason it doesn't always look great is that everyone has decided to do integer scaling and then scale down for fractional scaling instead of just rendering at the destination resolutions. Most things you care about for sharpness are already resolution independent (fonts, images) and would just work. Both Chrome and Firefox already render the whole browser in a resolution independent way but end up being rendered at 2x and scaled down for less sharpness and performance than just asking them directly to render whatever window size and scaling factor is needed. Hopefully Wayland will end up fixing this IMHO bad decision.
To avoid all this right now it's possible to just pick 1x or 2x and tweak font sizes to get a good mid-step. For a single screen this always works, but it makes combining different ones harder.
This is false. I can and do set whatever scale factor I want for each screen in sway and all apps are scaled correctly. This includes my browser, my text editor, my terminal, word processor and spreadsheet. There's literally no app I use where I have a problem.
All apps I use have a problem. Slack, Zoom, Chrome, Emacs, LibreOffice.
The only app I use that doesn't have a problem is Alacritty, which is the terminal emulator I kind of have to use to avoid this problem. Other terminal emulators I've tried do have this problem.
Anything that's GTK and Qt based will definitely be Wayland native and thus not have the XWayland issue with fractional scaling. So Libreoffice works fine and so does gnome-terminal. I use those daily. If you have problems with those there's something else wrong.
For the other examples it's probably XWayland scaling at 1x and then being scaled up instead of 2x and down. The patches to fix that exist but I'm not sure where they're already merged in. All those apps except Emacs should go Wayland native in the next few months though.
But right now, most GTK apps are not Wayland native and look bad on Wayland. Those that are Wayland native have so many bugs on Wayland that they are still objectively significantly worse than their Xorg alternatives.
That's not what I was saying. To clarify, everything that's GTK and Qt is already Wayland native and scales just fine. It's also not true at all that everything is full of bugs and unusable. In fact I can only think of a single Wayland-specific bug in a GTK app, and it's already fixed.
The biggest for me is actual tear-free rendering. All the different hacks in Xorg have never worked completely.
The other one that people value a lot is HiDPI scaling done "well". Mixed fractional scaling in Xorg doesn't really work and it's finally possible to do it. Although there I actually think it's still a half step and Wayland made the wrong choice in how to implement it. It should have been done client side for more performance and less fuzzyness. There's a chance that will also be fixed in the future.
Other than these it's a bunch of small things that are more technical than user-visible. Security is much improved for example. Some performance gains can be had from avoiding copying buffers. Etc.
Sadly sway seems very very Linux-centric. It depends on a device-enumerator that ships w systemd, which is quite an invasive prerequisite.
I’m playing/hacking w swc[0] on NetBSD, and I’ve worked out my daily-driver, which to be clear, is actually fit for ~nobody in the grand scheme, because it’s essentially just multiplexing terminals.
Right now it's reported by Linus Tech Tips[1], but I don't think I've seen anyone in the /r/VFIO community tried it yet (partly due to availability). I'm very curious about this as well and might as well get one and try it myself...
I'm full VFIO on an RTX 2060 max q and it's actually great. Error 43 is annoying but there are already workarounds - namely, certain VFIO settings (`vendor_id` in hyperv, and -laptop only- adding an acpitable to emulate battery).
AFAIK, RX 580 is the only exception for anything newer than Hawaii that doesn't have the reset bug (and only from certain vendor, Sapphire RX 580 I believe).
(Meanwhile Nvidia also removed the "error 43" limitation when it detected the card is being run in a VM, so VFIO scene is getting a lot more interesting in this generation.)
[1]: https://www.youtube.com/watch?v=ykiU49gTNak