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.
