Most active commenters
  • yjftsjthsd-h(8)
  • maxdamantus(6)
  • Silhouette(4)
  • cowtools(4)
  • 3np(4)
  • smoldesu(3)
  • wutbrodo(3)
  • throwawaylinux(3)
  • kaba0(3)

Are We Wayland Yet?

(arewewaylandyet.com)
96 points picture | 98 comments | | HN request time: 2.874s | source | bottom
1. smoldesu ◴[] No.32020659[source]
I'd argue the arrangement of this data is pretty deceptive. They give fields like "Desktop Environments" a green checkmark even though the vast majority are still unsupported. Furthermore, none of this addresses some of the real showstopper bugs like blurry UI scaling, screen locking issues, screensharing being largely unsupported or UB/artifacting problems on legacy apps. I'd like to assume good faith here, but the arrangement of this site is really odd: the first list is comprised of applications, and the "only thing" missing is color management/HDR, which is decidedly not an application.

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.

replies(1): >>32021366 #
2. hossbeast ◴[] No.32020806[source]
Have been using Wayland as my daily driver for about a year now, on my main PC, which I use for WFH. Big improvement for me.
3. notatoad ◴[] No.32020815[source]
Neat dashboard, but for my purposes only one datapoint matters: can I use it. And the answer to that is still no.
replies(2): >>32020834 #>>32020864 #
4. yjftsjthsd-h ◴[] No.32020831[source]
Oh sweet, I just have replace most of my applications and DE and everything will just work! /s
replies(3): >>32020885 #>>32021027 #>>32021294 #
5. wutbrodo ◴[] No.32020834[source]
What is your blocker?I'm curious because I recently switched to swaywm to fix some screen tearing, and I'm still figuring out how ready it is for primetime. It mostly works fine, but I'm getting occasional bugs with critical software like Chrome/Brave. It's giving me a very uncomfortable Ubuntu-in-2007 feeling.

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.

replies(1): >>32021502 #
6. akdor1154 ◴[] No.32020853[source]
Nice.

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 )

7. yjftsjthsd-h ◴[] No.32020864[source]
That's not really useful, though. "Is it usable" is not one item, but a list of things that you need it to do. Enumerating those items both makes it easier for you to evaluate and gives you something concrete to point people at when explaining why it sucks.
8. wutbrodo ◴[] No.32020885[source]
I have my qualms about Wayland, but this dashboard is quite obviously not directed at you? I don't see any suggestion that everyone should switch over now that there are a small handful of compatible apps per category.

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

replies(1): >>32021073 #
9. jpgvm ◴[] No.32020896[source]
Ah yes. Nvidia. The green death.

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.

replies(5): >>32020938 #>>32020954 #>>32021123 #>>32021211 #>>32024717 #
10. tastysandwich ◴[] No.32020935[source]
My biggest annoyance at this stage is a few blurry apps when using fractional scaling. Eg Calibre & GIMP.

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?

replies(3): >>32021085 #>>32021171 #>>32021261 #
11. doodlesdev ◴[] No.32020938[source]
> 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.

replies(1): >>32021157 #
12. BeetleB ◴[] No.32020954[source]
Interesting how the pendulum swings.

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.

13. Silhouette ◴[] No.32020958[source]
IMHO the most frustrating thing about Wayland is how it's fracturing the Linux landscape again.

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.

replies(1): >>32021181 #
14. risho ◴[] No.32021027[source]
ubuntu and fedora are both shipping wayland out of the box with gnome which covers the overwhelming majority of every day users. most people are already using wayland. it's not our fault you decided that you want to use fluxbox on gentoo
replies(2): >>32021110 #>>32021692 #
15. yjftsjthsd-h ◴[] No.32021073{3}[source]
That is a possible interpretation, true. It reads to me as somebody trying to show a page full of green check marks to pretend that Wayland is totally ready to use and everybody should switch already. I suppose it might be intended as a list of things that are compatible, in which case yes it's quite useful.
16. anotherhue ◴[] No.32021085[source]
That's a consequence of going through Xwayland. If there's a wayland native version of those apps it should be crisp.
17. ddtaylor ◴[] No.32021104[source]
> There is currently no accelerated GLX support when running a GNOME Wayland session no top of the NVIDIA drivers, meaning X11 OpenGL applications will use software rendering.

Yikes.

replies(1): >>32024159 #
18. yjftsjthsd-h ◴[] No.32021110{3}[source]
> most people are already using wayland

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?

replies(3): >>32021284 #>>32021346 #>>32022066 #
19. ddtaylor ◴[] No.32021123[source]
I use Nvidia for gaming systems that only run Windows and never get any of my important credentials entered on them; they strictly run games only. For development and non-gaming tasks I use an Intel integrated graphics system on Linux instead. Wayland on the iGPU systems runs great!
replies(1): >>32021599 #
20. jpgvm ◴[] No.32021157{3}[source]
On Arch they tend to use flags files in `$HOME/.config` can generally just add `--ozone-platform=wayland` to force it to use Wayland.
replies(1): >>32021698 #
21. porjo ◴[] No.32021171[source]
I recently tried Krita [0] which supposedly supports fractional scaling but still looks blurry on my Fedora 36/Gnome desktop!?

[0] https://krita.org

22. cowtools ◴[] No.32021181[source]
Do you have xdg-desktop-portal-gnome installed?

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.

replies(2): >>32021393 #>>32021412 #
23. zamadatix ◴[] No.32021211[source]
Nvidia with Sway actually works well now since the big GBM announcement last fall. Some are even using the newer open source driver but I haven't bothered yet as it is still alpha quality for the desktop use case. For me it doesn't matter too much until Wayland HDR lands though, my non HDR system was already AMD because the GPU support was better.
24. maxdamantus ◴[] No.32021261[source]
> 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).

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...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1679335

replies(3): >>32022047 #>>32022079 #>>32023293 #
25. AdmiralAsshat ◴[] No.32021271[source]
I imagine I'll be on X until Cinnamon decides to switch to Wayland.
26. csande17 ◴[] No.32021284{4}[source]
I'd imagine they're basing their conclusions of off telemetry data from Ubuntu and Fedora. After all, Linux is just like Firefox: everyone who uses it absolutely loves sharing information about themselves with corporations! Telemetry data therefore presents an accurate, unbiased picture of the entire userbase.
replies(1): >>32021336 #
27. EamonnMR ◴[] No.32021294[source]
Reminds me of the early days of Ubuntu with the fierce competition between KDE, Gnome, and Xfce
28. Weebs ◴[] No.32021298[source]
Push to talk is another important one (for me)
replies(1): >>32022031 #
29. yjftsjthsd-h ◴[] No.32021336{5}[source]
Lol. But it's actually worse than that; Firefox enables telemetry by default and then ignores everyone who opts out, but I'm not aware of any Linux distros that enable it by default (Ubuntu apparently used to, until it silently broke and then they removed it: https://itsubuntu.com/no-more-popularity-contest-package-by-...).
30. markstos ◴[] No.32021346{4}[source]
Maybe they count Chromebooks? Those use Wayland.
replies(1): >>32021481 #
31. markstos ◴[] No.32021366[source]
I’ve been using Wayland for over a year with screen sharing, photo editing, video production.

Definitely less Jane resizing windows with Wayland.

32. Silhouette ◴[] No.32021393{3}[source]
I have a standard, regularly updated Ubuntu 22.04.

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.

replies(3): >>32021440 #>>32021467 #>>32021912 #
33. phkahler ◴[] No.32021407[source]
CAD program -> Solvespace. It's been native Wayland for years now ;-)
34. dopeboy ◴[] No.32021410[source]
I'm on ubuntu 20.04 and thinking of upgrading to 22.04. Does Zoom work with Wayland?
replies(2): >>32023710 #>>32024172 #
35. smoldesu ◴[] No.32021412{3}[source]
Part of the problem, as I understand it, is that the onus is now on each individual desktop environment to provide it's own implementation of screensharing. If Wayland made this an optional, standardized feature, maybe downloading packages and checking with our distro maintainers wouldn't be a part of this.

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.

replies(1): >>32021848 #
36. binarysneaker ◴[] No.32021440{4}[source]
Change takes time. There's always Windows... /s
replies(1): >>32021474 #
37. viraptor ◴[] No.32021458[source]
> Image editor: Inkscape

That entry is both mislabelled and way too short. Inkscape is there for illustrating / vectors, but image editing has other apps.

replies(1): >>32021934 #
38. sylware ◴[] No.32021464[source]
missing the steam client.

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).

39. encryptluks2 ◴[] No.32021467{4}[source]
The fix is installing the appropriate app or participating in your distro to get it automatically fixed. If you can't be bothered to do anything but rage quit when you don't get your way you'd be better off on Mac.
replies(1): >>32021527 #
40. Silhouette ◴[] No.32021474{5}[source]
Change takes time.

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.

replies(1): >>32023515 #
41. yjftsjthsd-h ◴[] No.32021481{5}[source]
Hah, I forgot about that. A bit like calling Android Linux, but yes that probably does dwarf the rest of us.
42. rvz ◴[] No.32021496[source]
Here we go again. We see multiple fissures in the Linux Desktop ecosystem all because of ONE system component. The same happened with systemd vs init.d and now we have this contraption.

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.

[0] https://news.ycombinator.com/item?id=30983400

[1] https://github.com/vector-im/element-web/issues/21147

43. notatoad ◴[] No.32021502{3}[source]
I honestly don't know. I installed fedora, and it wouldn't load to desktop. Switching to an X session fixed my problem, so that was the end of my troubleshooting. I just wanted my computer to work, not to fuss with display managers.
replies(2): >>32021874 #>>32032870 #
44. Silhouette ◴[] No.32021527{5}[source]
If you can't be bothered to do anything but rage quit when you don't get your way you'd be better off on Mac.

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.

45. heywoodlh ◴[] No.32021599{3}[source]
I am in the exact same boat.

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 :)

46. ixtenu ◴[] No.32021692{3}[source]
> most people are already using wayland.

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.

[0] https://linux-hardware.org/?view=os_display_server

47. doubled112 ◴[] No.32021698{4}[source]
I had mixed results with the flags files.

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.

48. cowtools ◴[] No.32021848{4}[source]
I'm not sure I completely agree. You have a middleground where smaller DEs (wayfire, sway, etc.) huddle around larger "hub" implementations of wayland like wlroots in the same way that X11 DEs used Xorg.

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.

replies(1): >>32021899 #
49. magicalhippo ◴[] No.32021874{4}[source]
I just tried Wayland last week on my KDE Neon install. Tried playing a movie from my NAS share (smb). Nothing... Local file worked. Switched to X and the NAS file played just fine, exact same steps.

No idea how Wayland would affect a Samba share, but like you I just wanted it to work so that was that for now.

50. nsajko ◴[] No.32021899{5}[source]
The information you present is completely consistent with what smoldesu said.
replies(1): >>32021965 #
51. cowtools ◴[] No.32021912{4}[source]
>In reality like almost every other Ubuntu user I've talked to in real life [...]

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!

52. syntheweave ◴[] No.32021934[source]
It's not even an honest assessment of usability. Tablet support on Wayland is hit-and-miss, depending on your vendor. There are some open issues in Inkscape around it but they might not even be resolvable by the Inkscape devs because of the whose-bug-is-it dependencies involved.

But I run xorg for this reason.

53. cowtools ◴[] No.32021965{6}[source]
Maybe I should be more specific:

>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.

replies(1): >>32023064 #
54. bravetraveler ◴[] No.32021984[source]
I am /shrug
55. aethe ◴[] No.32022031[source]
This was also a big one for me. The best workaround I've come up with so far is to set up a global hotkey to toggle microphone mute in KDE, and then set my Discord (etc.) to have very sensitive "voice activation" settings. Essentially I've replaced push to talk with "push to toggle mute". Not the same thing, but I got used to it pretty quick.

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).

replies(1): >>32023747 #
56. 3np ◴[] No.32022047{3}[source]
This is currently working fine for me with the wayland backend (not xwayland) on Firefox in sway. The details escape me but I think it started working properly since a release during the past ~6-9 months.

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 :)

replies(1): >>32022406 #
57. throwawaylinux ◴[] No.32022066{4}[source]
Xorg was the stagnant monoculture though, and you were complaining about an alternative to it because it does not suit you exactly.
replies(1): >>32022283 #
58. nyanpasu64 ◴[] No.32022079{3}[source]
Frankly I'd be happy with integer window scaling and fractional font scaling (like Xft.dpi, progress at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...).
59. yjftsjthsd-h ◴[] No.32022283{5}[source]
Xorg resulted in a stagnant monoculture in the display server itself, but allowed arbitrary stuff to build on top. If wayland results in a monoculture of desktop environments, that will be a regression. On the other hand, yes; if wayland results in a healthy ecosystem of compositors that are actually as functional as Xorg was (because by all accounts that should be a low bar, right?) then we will come out far ahead.
replies(1): >>32023031 #
60. maxdamantus ◴[] No.32022406{4}[source]
Right, the effective DPI switching works for Firefox on Wayland, but like all other applications on Wayland, fractional scaling will result in blurriness. I was looking into this less than 6 months ago, and I don't see any relevant updates since then and can see various other recent reports of the same issue.

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.

replies(1): >>32022632 #
61. georgia_peach ◴[] No.32022464[source]
Only thing holding me back is Barrier support.

https://github.com/debauchee/barrier/issues/109

62. 3np ◴[] No.32022632{5}[source]
output $MONITOR scale 1.25 in sway; no blurriness.

IIRC the only thing I eventually did to make things work was setting env vars

  MOZ_ENABLE_WAYLAND=1
  MOZ_WAYLAND_USE_VAAPI=1
(You probably already know this but check `window protocol` under about:config and/or use the xeyes method to verify that it's indeed not falling back to Xwayland. I mention this because any time I experienced blurriness, Xwayland's been in the loop and xeyes is a quick way to check that for any app)

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)

[0]: https://codeberg.org/dnkl/foot/issues/714

replies(2): >>32022946 #>>32027298 #
63. exabrial ◴[] No.32022699[source]
I have a question because I have not kept up with desktop remix for about 10 years. 10 years ago you could download a proprietary driver for Linux and Nvidia and it would actually work great. Is that still the case today or are you just completely hosed if you have Nvidia graphics?
replies(1): >>32022851 #
64. JellyBeanThief ◴[] No.32022851[source]
That's how it works for me on Fedora 36. I use GNOME and drive four monitors including my laptop's with the 515.57 version of proprietary driver. It works very well for day-to-day use on X11, and very well for day-to-day use on Wayland.

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.

replies(1): >>32022952 #
65. maxdamantus ◴[] No.32022946{6}[source]
I really don't think this is correct. It is possible that you're just not able to notice the blurriness due to the scaling method used, the resolution of the display and the fact that text rendering tends to be blurred nowadays anyway [0], but I'm 95% sure that you'll be looking at blurred output, as documented [1]:

> 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...

replies(1): >>32023349 #
66. exabrial ◴[] No.32022952{3}[source]
So basically Wayland/Nvidia is works pretty well, just no gaming?
67. throwawaylinux ◴[] No.32023031{6}[source]
> Xorg [...] allowed arbitrary stuff to build on top.

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.

replies(1): >>32023736 #
68. smoldesu ◴[] No.32023064{7}[source]
wlroots is really not that mature, and it's sort of a too-little-too-late situation. A lot of DEs are just never going to get around to switching to Wayland, but that doesn't mean they're going to stop development either. That's a pretty considerable fragmentation that people shouldn't take lightly.

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.

replies(1): >>32023546 #
69. kaba0 ◴[] No.32023293{3}[source]
I’m fairly sure it only happens on XWayland windows, and that in general it is not possible to fractional scale something without the aid of the client. OSX also has a similar restriction where only integer scaling is allowed (but it is less of a problem there due to higher resolutions in general).

There is fractional scaling though under Wayland which works fine for Wayland applications.

replies(1): >>32023328 #
70. maxdamantus ◴[] No.32023328{4}[source]
This is not limited to XWayland windows. See the relevant issues:

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.

replies(1): >>32023593 #
71. 3np ◴[] No.32023349{7}[source]
Maybe screenshots would be helpful!

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?

replies(1): >>32024677 #
72. kaba0 ◴[] No.32023515{6}[source]
The thing is that with bazaar-style development there is no other way to solve it.

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.

73. kaba0 ◴[] No.32023546{8}[source]
That’s why Wayland has XWayland for seamless backwards compatibility with X applications? That’s pretty much the equivalent of a PA sink in PipeWire.

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.

74. tadfisher ◴[] No.32023593{5}[source]
Integer scaling has already been implemented and doesn't result in pixel-snapping artifacts and broken text rendering. I fear that fractional scaling will result in exactly this, similar to CSS 1.0.

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.

replies(1): >>32027868 #
75. oynqr ◴[] No.32023710[source]
It probably still abuses the Gnome screenshot API instead of using pipewire, but it might work.
76. yjftsjthsd-h ◴[] No.32023736{7}[source]
>> Xorg [...] allowed arbitrary stuff to build on top.

> 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.

replies(1): >>32024906 #
77. oynqr ◴[] No.32023747{3}[source]
Have a look at https://github.com/waycrate/swhkd, last time I tried to use it it was still quite janky, but it might have improved since.
78. vnm ◴[] No.32024103[source]
Once a year I switch to Wayland for a few hours to see if I can get my work done on it, and the result is always negative.
79. spystath ◴[] No.32024159[source]
I don't think that's true since about a year ago.

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

80. hkmaxpro ◴[] No.32024172[source]
Yes, as of 2 weeks ago. https://old.reddit.com/r/linux/comments/vhw3x3/zoom_can_now_...
81. aasasd ◴[] No.32024417[source]
So no one thought of making a compatibility layer?
replies(1): >>32025917 #
82. steve_gh ◴[] No.32024555[source]
Either Teams etc just work and allow screen sharing, or they doesn't.
replies(1): >>32025494 #
83. LeanderK ◴[] No.32024626[source]
I don't use linux but I thought Wayland is old news. I remember the talk about switching to waylaid like 6 years ago. Is it still niche?
84. maxdamantus ◴[] No.32024677{8}[source]
> Maybe screenshots would be helpful!

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
Admittedly, I should probably have reënabled subpixel antialiasing in the v40 examples, since the theory behind v40 kind of assumes subpixel antialiasing (maybe an exercise for a reader), but it should at least be clear from these images that the simulated fractional scaling that currently exists in sway/Wayland is suboptimal.

> 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

replies(1): >>32031444 #
85. sam_lowry_ ◴[] No.32024717[source]
You can drop Pipewire, and use alsa + dmix for system-wide sound mixer.

However, if you are also using ungoogled Chromium from Arch, you are doomed to use Pipewire.

86. butz ◴[] No.32024811[source]
Why Qt5 problems on GNOME are not mentioned? Am I only one who has problems with KeepassXC on GNOME, where program window does not have correct decorations (shadows) and doesn't appear in window switcher (alt+tab)?
replies(2): >>32024937 #>>32025863 #
87. throwawaylinux ◴[] No.32024906{8}[source]
I don't see anything you wrote that means you can't build arbitrary stuff on top of Wayland.
88. ChuckNorris89 ◴[] No.32024937[source]
Gnome devs pretend Qt doesn't exist, so for them this is not a problem, as you should only be using Gnome/GTK apps according to them (aka "you're holding it wrong")

KDE is much better at displaying GTK apps than Gnome is at Qt apps.

89. KSPAtlas ◴[] No.32024938[source]
Needs an update, I can run Sway on NVIDIA with a big limitation: XWayland is extremely buggy
90. zackmtaylor ◴[] No.32025494[source]
On GNOME?
91. ysleepy ◴[] No.32025863[source]
I literally had this problem yesterday. All the label and field text was invisible. For some reason it worked after a snap reinstall of keepassxc. Why it is snap, I have no idea.

Apart from lots of display switching and scaling causing quirks everywhere.

92. Tajnymag ◴[] No.32025917[source]
Like XWayland?
replies(1): >>32027290 #
93. aasasd ◴[] No.32027290{3}[source]
Well there it is. If there's a compatibility layer, then what it matters if “we are Weyland” or “not Weyland”.
94. Fnoord ◴[] No.32027298{6}[source]
On my Sway config, if the application uses X, the titlebar contains [x] before the rest of the title name. Highly recommended.

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.

95. maxdamantus ◴[] No.32027868{6}[source]
The problem is that this is what currently happens when people enable fractional scaling (ie, setting the scale to 1.5 rather than 2), which I'm fairly sure is common.

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.

96. 3np ◴[] No.32031444{9}[source]
That is very insightful and you're on point!

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.

97. wutbrodo ◴[] No.32032870{4}[source]
Oh, wow, didn't expect it to be that straightforward haha