So the good thing about Linux distros switching to Wayland long before Wayland is remotely ready is that contact with real-world users will make the "pain points" visible so they can be fixed. But the bad thing is. I do not actually believe the "pain points" will be fixed. Ever
Several Transgender Wolf Girls
in reply to mcc • • •Joe
in reply to mcc • • •mcc reshared this.
Alex P. 👹
in reply to mcc • • •one time gnome just stopped respecting the concept of having more than one XScreen (the second digit in "DISPLAY=:0.0"), and i wrote red hat to ask them about it (i worked for a company that had a support contract, at the time), and they wrote back "we forgot what that did so we just nuked it entirely, nobody who runs linux uses a random collection of heterogeneous displays anymore, right?"
i feel like i've seen this interaction play out many times in my life now
mcc reshared this.
Dan Ballard
in reply to Alex P. 👹 • • •mcc
in reply to Dan Ballard • • •bob
in reply to mcc • • •mcc
in reply to bob • • •Irenes (many)
in reply to mcc • • •Graham Sutherland / Polynomial
in reply to mcc • • •mcc reshared this.
aeva
in reply to Graham Sutherland / Polynomial • • •Graham Sutherland / Polynomial
in reply to aeva • • •Graham Sutherland / Polynomial
in reply to Graham Sutherland / Polynomial • • •Graham Sutherland / Polynomial
in reply to Graham Sutherland / Polynomial • • •Graham Sutherland / Polynomial
in reply to Graham Sutherland / Polynomial • • •mcc
in reply to Graham Sutherland / Polynomial • • •Graham Sutherland / Polynomial
in reply to mcc • • •mcc
in reply to Graham Sutherland / Polynomial • • •mcc
in reply to Graham Sutherland / Polynomial • • •Matthew Miller
in reply to aeva • • •@aeva @gsuberland
It's funny because it's true.
By which I mean: there are not, actually, any magical infinite funds to support desktop Linux, because that has no commercial value whatsoever, but it's 100% free to shit on people who are volunteering their time to try to make things better as best they can. You can earn valuable Mastodon Snark Points for it, which you can cash in for fuck all in actually making things better.
Or you could, you know, not so that.
mcc
in reply to Matthew Miller • • •Matthew Miller
in reply to mcc • • •@aeva @gsuberland
The people who sell computers don't have a great incentive to make them "work". They just need to Windows well enough. If you want that, that's for sale. If you don't, well, there's no commercial interest in anything else. So,we have to do what we can. The people working on it know _to the breaking point of their souls_ that it isn't perfect.
mcc
in reply to Matthew Miller • • •Janne Moren
in reply to mcc • • •What was the alternative though? The Xorg maintainers were saying that nope, they're not going to continue developing it any longer. What should distros have done?
mcc
in reply to Janne Moren • • •mcc
in reply to mcc • • •Scott Leggett
in reply to mcc • • •@mattdm @aeva @gsuberland This is an incredibly rose tinted description of X.
X did not work. It was horribly broken for multiple screens with different DPI, and barely functional even when the DPIs matched. Tearing was practically unfixable even when you used the recommended pile of hacks. Xorg.conf sucked to configure. Screen hotplug wasn't a thing. Accelerated games randomly caused the window manager to break. And all that's without even mentioning security.
Wayland fixes all of that.
mcc
in reply to Scott Leggett • • •@smlx @mattdm @aeva @gsuberland "Wayland fixes all of that." Wayland does not work on ONE SCREEN with a DPI. That is what Aeva and I are complaining about. Fuck off.
Also, I do not *want* to use X. I want working Wayland, and I want it in 2015. I want what Windows could give me in 2015. Or what Mac OS X could give me in 2003 for that matter. Wayland has replaced the unfixable pain points of X with a new set of pain points that it is not clear to me are in principle fixable. I'm not impressed.
main__
in reply to mcc • • •mcc
in reply to main__ • • •Sashin
in reply to mcc • • •aeva
in reply to mcc • • •AlgoCompSynth by znmeb 🇺🇦
in reply to mcc • • •Pretty much the only way to get bugs fixed is to run either Fedora Rawhide or Debian Sid or both and file bug reports against them. Catch them early in the cycle or they get papered over in the corporate pressures to ship Red Hat Enterprise and Ubuntu LTS.
I'm pretty happy running Bluefin and doing everything adventurous in Distrobox containers, but that's not the right strategy for embedded.
okanogen VerminEnemyFromWithin
in reply to mcc • • •Or maybe more Jennings?
GreenDotGuy
in reply to mcc • • •mcc
in reply to GreenDotGuy • • •GreenDotGuy
in reply to mcc • • •That's unfortunately a problem that won't go away until the programs are compiled (or configured) to run on toolkits that run natively in Wayland. I've been filing bugs and pushing for developers to make the switch for a while.
Unfortunately, a lot of popular distros froze their packages for the last set of stable releases right before a tipping point was reached where underlying libraries had the native Wayland fractional scaling included. It won't fix the way XWayland scales, but it did add functionality that convinced a lot of developers to pay attention to making apps look good natively instead of relying on XWayland.
I still notice some apps on Windows that do this too, they render stuff inside their frame sorta goobely because they use an old library that scales up from a lower resolution.
I wish XWayland didn't even scale by default, and instead the Mutter developers added a little 'scaler' widget to the menu bar of apps running on it. The problem with the fuzziness isn't Wayland, it's not embracing Wayland; and the 'completely transparent' way they made X
... show moreThat's unfortunately a problem that won't go away until the programs are compiled (or configured) to run on toolkits that run natively in Wayland. I've been filing bugs and pushing for developers to make the switch for a while.
Unfortunately, a lot of popular distros froze their packages for the last set of stable releases right before a tipping point was reached where underlying libraries had the native Wayland fractional scaling included. It won't fix the way XWayland scales, but it did add functionality that convinced a lot of developers to pay attention to making apps look good natively instead of relying on XWayland.
I still notice some apps on Windows that do this too, they render stuff inside their frame sorta goobely because they use an old library that scales up from a lower resolution.
I wish XWayland didn't even scale by default, and instead the Mutter developers added a little 'scaler' widget to the menu bar of apps running on it. The problem with the fuzziness isn't Wayland, it's not embracing Wayland; and the 'completely transparent' way they made XWayland work makes it seem like Wayland itself is the problem.
mcc
in reply to GreenDotGuy • • •mcc
in reply to mcc • • •GreenDotGuy
in reply to mcc • • •Yep, and Java itself has a long way to go. That one still bites me.
Re: the electron apps though... I've found some environment variables and CLI arguments that I put in the launcher commands that make most of them render crisply. Would you be interested in having me share what I use for a few common ones like VSCode or Slack?
mcc
in reply to GreenDotGuy • • •Josh Simmons
in reply to GreenDotGuy • • •mcc
in reply to Josh Simmons • • •Josh Simmons
in reply to mcc • • •mcc
in reply to Josh Simmons • • •Why Not Zoidberg? 🦑
in reply to mcc • • •vignesh
in reply to mcc • • •mcc
Unknown parent • • •Joe
Unknown parent • • •artemist
in reply to mcc • • •i feel like wayland has been improving, but impressively slowly.
like getting an ime (to input mandarin) to work in wayland a few years ago was awful, now every application i've tried Just Works.
they finally defined how to do color management and hdr... after 12 years. maybe in another 2 compositors will support it.
for some reason they didn't define fractional scaling at the start, so it took years for there to be any work on it.
mcc
in reply to artemist • • •artemist
in reply to mcc • • •i think fractional scaling support got into the toolkits in 2023, then the compositors in 2024-2025. it seems to work fine for me on firefox and some stock gtk/qt applications on sway.
maybe they'll actually have addressed many of the pain points in 2035, just in time for you to find more
hikari 🌟 (fell out of the sky)
in reply to mcc • • •mcc
in reply to hikari 🌟 (fell out of the sky) • • •hikari 🌟 (fell out of the sky)
in reply to mcc • • •mcc
in reply to hikari 🌟 (fell out of the sky) • • •@hikari that's when we'll have worked out the simple problems with our wayland stacks and start working on the hard ones
and consequently find out which hard ones are now excluded
Thad
in reply to mcc • • •Scien
in reply to mcc • • •Another issue is distro packaging. I used to have so many kde papercuts on arch that just disapeared when I switched to NixOS.
And then I had even less issues when I switched to a tiling window manager like Niri. But, well, to be fair it still "had issues" - the issues were just in the surrounding ecosystem (swayidle, gtklock, etc have weird bugs that are reported but not fixed).
Still, it's nice to be off of X11. Wayland has shit ton of issues but I actually had more fuckery go around on x11, somehow.
mcc
Unknown parent • • •mcc
Unknown parent • • •Jonathan Ward
in reply to mcc • • •mcc
in reply to Jonathan Ward • • •Jonathan Ward
in reply to mcc • • •mcc
in reply to Jonathan Ward • • •mcc
Unknown parent • • •Big Kumera Energy
in reply to mcc • • •I've been using wayland for years, since fedora first shipped it.
The clipboard issues can be nightmarish. It's so frustrating. I just want to copy and paste. Why is something different in the buffer of the right-click paste function and the ctrl+v function.
mcc
in reply to mcc • • •mcc
in reply to mcc • • •Glyph
in reply to mcc • • •unattributed 𓂃✍︎
in reply to Glyph • • •This seems to be something that infects the open source world... Instead of understanding the codebase of something, just go ahead and reinvent it -- only worse.
We've seen it before with PulseAudio, systemd, Gnome, etc. Only a few times that I can think of that it has been handled in a good way: OpenOffice.org->LibreOffice, Audactiy's upcoming new version, for example.
IMO - with Wayland, I wish someone had really taken the time to completely understand the X protocol stack instead of just throwing everything out and starting over. Yes, I get it that there were things that the original stack was never intended to handle -- but there certainly could have been much better ways to start from the X base, refactor the code, and then implement the changes needed to support newer devices and configurations.
filipa mv
in reply to unattributed 𓂃✍︎ • • •@unattributed @glyph
with totally unearned confidence from understanding exactly zero of any of the problems involved,
part of me wishes we’d just give up entirely on reinventing this wheel and go whole hog on reimplementing Apple’s APIs too to bottom and calling it done
mcc
in reply to filipa mv • • •walnut 🌱
in reply to unattributed 𓂃✍︎ • • •@unattributed@glyph@mccpipewire managed to be an excellent transition from alsa, pulseaudio, and jack all at the same time.
And I'm not an xorg or wayland dev, but from what I understand a lot of the original wayland architects were x11 devs who did know the problems with it and then totally over corrected when making wayland, avoiding the same mistakes but making new ones.
mcc
in reply to walnut 🌱 • • •Scien
in reply to mcc • • •Many rust compositors utilize smithay: github.com/Smithay/smithay
This includes Niri (what I use) and Cosmic. So you technically have choices! Maybe not very many, but choices!
GitHub - Smithay/smithay: A smithy for rusty wayland compositors
GitHubThe Witch of Crow Briar
in reply to Scien • • •mcc
in reply to The Witch of Crow Briar • • •Scien
in reply to mcc • • •@crowbriarhexe Predictably it also helps (not solves, could you imagine?) the kind of splintering issue you were talking about. Here's the niri developer fixing an issue in smithay for Niri, that, ofc, also helps cosmic de:
github.com/Smithay/smithay/pul…
xdg-shell, layer-shell, session-lock: Track last acked configure in MultiCache by YaLTeR · Pull Request #1817 · Smithay/smithay
GitHubScien
in reply to Scien • • •@crowbriarhexe ofc, wlroots is often considered a more substantial shared ground for many wayland compositors. Still.
Tbh, I feel like none of this would be so nearly as severe if kde and gnome wont so focused on making completely separate compositor implementations. Sigh
mcc
in reply to Scien • • •James Henstridge
in reply to mcc • • •I'd expect most GNOME apps to work reasonably well on other compositors. There's not that much stuff that depends on Mutter specifically.
You might need to get an xdg-desktop-portal backend sorted out if you want screen sharing to work in web browsers and the like. But you might be able to e.g. reuse the wlroots backend if you implement the right extensions.
Simon Raboczi
in reply to mcc • • •mcc
in reply to Simon Raboczi • • •Simon Raboczi
in reply to mcc • • •mtp
in reply to mcc • • •Jakob (Jack/Jackie)
in reply to mcc • • •James Mitchell
Unknown parent • • •mcc
in reply to James Mitchell • • •HP van Braam
in reply to mcc • • •I'm probably unreasonably lucky. I switched to Wayland for Fedora 40, a year ago, ish? On gnome-shell I've had no issues.
The only thing really is that I had to switch from parcellite to a gnome-shell extension to do clipboard management.
I do avoid nvidia like the plague tho, all of my machines have AMD/Intel gpus only (a variety, 6600M, AMD iGPU, Intel iGPU, and 6950XT, I have too many computers)
What kind of problems do you run into? not at all trying to argue, just really curious!
mcc
in reply to HP van Braam • • •@hp 1. My last two Linux laptops have been 1.5x DPI. This is poorly supported. X11 can limp through, pure Wayland can limp through, but X11 app with Wayland compositor on Gnome is The Bad Place and I can't get out of that place without switching DEs. To my knowledge you can't just hotswap out Mutter while still using GNOME.
2. In order to get good gpu/Wayland performance, I bought an AMD based machine. Now I have Linux kernel incompatibilities with this one AMD chipset.
mcc
in reply to mcc • • •mcc
in reply to mcc • • •HP van Braam
in reply to mcc • • •I do streaming, that has not been a problem for me. OBS on top of my gnome stack with pipewire seems 100% solid.
So that, at least, should be possible. I don't think that working has anything to do with my (apparently) goldilocks hardware!
HP van Braam
in reply to mcc • • •I have a HP Zbook fury 17.3 with a xeon and a Radeon pro w6600m, it's a really nice machine. Probably another reason then why I have no issues...
But such machines do exist my previous laptop was a Dell precision with a similar config.
HP van Braam
in reply to mcc • • •ah, wow, that's rough. Particularly the AMD thing. I've had good luck with the Mesa developers when I've had issues in the past. Maybe they can help?
And yeah, all my boxes are 4K, with 200% scaling, not fractional so that explains then why I never had an issue.
Thanks for explaining! Maybe the Mutter people will fix the x11 fractional scaling thing. One can hope...
forza4galicia
in reply to mcc • •mcc
in reply to forza4galicia • • •@forza4galicia @hp
$ uname -r
6.12.48+deb13-amd64
On the Thinkpad T14 Gen 3 AMD, this will often kernel panic when attempting to wake from sleep rather than waking.
There was some earlier version of the kernel that didn't have this problem. I had it, then it went away, then it came back. I've been given the advice to figure out which kernel versions I've used and try to downgrade, but not had time to test this.
HP van Braam
in reply to mcc • • •@forza4galicia have you tried this with a Fedora Live usb? My small laptop is a tuxedo "Pulse 14 Gen3", that's a "Ryzen 7 7840HS" so I think it is slightly newer than your amd based laptop.
But! It suspends and wakes up flawlessly every time. But I run Fedora 42 on it, so that just might be worth trying?
If it works I'm sure that aliening the Fedora kernel into Debian isn't that hard.
mcc
in reply to HP van Braam • • •@hp @forza4galicia The failure happens randomly. Sometimes it happens multiple times in a day, sometimes over a week can pass without it occurring. I've yet to figure out if it can be forced by just sleep-waking the computer in a loop. If it requires a normal usage pattern, I don't think I can reproduce a week's worth of normal usage off a liveCD. If I test in a loop and THAT works, maybe.
What kernel is your Fedora 42 running?
HP van Braam
in reply to mcc • • •@forza4galicia Right now it is running 6.16.7-200.fc42.x86_64
I guess you could try just getting the srpm and the .config and build it?
mcc
in reply to HP van Braam • • •HP van Braam
in reply to mcc • • •@forza4galicia that might be a good first thing to try, yeah.
I was just wondering if maybe the difference wasn't necessarily the kernel version as the config options used, but that's maybe better tested later!
mcc
in reply to HP van Braam • • •forza4galicia likes this.
forza4galicia
in reply to mcc • •I am with a debian with repositories testing, experimental(debian 14) and unstable, and a kernel linux 6.17.6+deb14, and it is working well.
Equally,my processor is AMD A10-9600P (then ,probably,with more stable support).
My (switchable) graphics are Radeon R5 integrated on SoC , and an dedicated Radeon R7 M340
Sarah Jamie Lewis
Unknown parent • • •@dan_ballard
That kind of webpage/browser fragmentation applied to graphical applications is an explicit design goal of wayland.
Protocol consolidation is an output of that (see the xdg namespace), but there are already enough ideological gaps between implementations that certain protocols (e.g. client window management / the ability to position a window either in a global or relative space) is unlikely to ever fall into the set of shared behaviour across all popular compositors.
mcc
in reply to Sarah Jamie Lewis • • •Dan Ballard
in reply to mcc • • •oh that dove tails with some work someone one doing writing a Wayland protocol fuzzer and finding they could straight up crash some compositors.
So unlike x where there was one server we all used and one library to talk to it, Wayland hasany implementations one per compositor? And way less shared library code? Ew. That seems like a terrible direction and regression. And splitting already limited resources further
Sarah Jamie Lewis
in reply to Dan Ballard • • •@dan_ballard
With a few exceptions, most wayland compositors share much of the same base code (libwayland and wlroots which covers wire protocols, buffer management etc.)
The main issue is in the layer above that. The wayland standard has very little to say in regards to how compositors interpret the protocols / what protocols they support etc.
The best analogy I can come up with is "this webpage works best on IE6" e.g. "this app works best on Mutter"
mcc
in reply to mcc • • •Sarah Jamie Lewis
in reply to mcc • • •@dan_ballard
Yeah neither Kwin nor Mutter depend on wlroots (though they do share other wayland base libs, and much of the code in wlroots can be traced back to such core implementations)
That first point might have been better stated as: 'there is a set of core functionality that defines "wayland" and most compositors agree on what that is to the extent that even independent implementations behave consistently. The main issue is in the layer above that...'
mcc
Unknown parent • • •Dan Ballard
in reply to Sarah Jamie Lewis • • •to MCC's point about "how good the basic standard is" it is sounding at least to me that if "client window management / the ability to position a window either in a global or relative space" isn't agreed upon and standard between implementations than... it sounds not as good as I'd have hoped for or presumably liked? that sounds like a colossal headache unless there's some benefit to messages about position being interpreted differently depending on which DE's compositor receives them
mcc
Unknown parent • • •Sarah Jamie Lewis
in reply to Sarah Jamie Lewis • • •@dan_ballard
And so determining a "bug" from a "missing feature" from a "it's a tenet of this compositor that we do it that way and we won't consider alternatives" is necessarily a hard compositor-specific question rather than a general "wayland" question.
(I say all of the above as someone actively writing a wayland compositor, and slowly moving my workflow/systems to wayland-only)
Dan Ballard
in reply to Sarah Jamie Lewis • • •mcc
Unknown parent • • •Dan Ballard
Unknown parent • • •Dan Ballard
in reply to mcc • • •@sarahjamielewis right I guess the genesis of this was when the "lets have one OS and one UI for mobile and desktop" was getting into full swing with a lot of folks at the time looking to de-prioritize the desktop and focus more on mobile support... which, let's take a look at how the mobile linux deployment vs desktop market share has gone in the last 15-20 years and... oh my.
Even steamdeck with steamos, a mobile ish linux disto is still currently running Xorg I believe.
super fun being a linux desktop user the last decade and a half
Dan Ballard
in reply to Dan Ballard • • •For I am CJ
in reply to mcc • • •Much of what 'makes it into a production' is often driven by corp backing... where, at the core, a lot of that will always be:
- engineers doing whimsical, often incompetent shit.. so they can get a "mission accomplished banner" for their 'goals & objectives'
- even more incompetent 'leader-shit' people... making arguably the worst possible decisions, because they need to be seen 'doing something'... undermining what competent work did somehow manage to 'make it through' to their level
mcc
Unknown parent • • •@dan_ballard @sarahjamielewis *points at the top of the thread* so the thing is that Wayland's been around since 2015, but "not quite there" so no one used it, now all the distros are jumping to it, now we have to actually fix the problems. But there are so many problems.
This was my original point.
Dan Ballard
Unknown parent • • •Sarah Jamie Lewis
Unknown parent • • •@dan_ballard
But e.g. I have in-house tools that rely on being able to layout windows automatically. Wayland is philosophically against that, so either I:
1) rewrite so that all window management takes place in a single window (MDI style) - pushing all of that complexity down into the app
2) wait for (or in my case develop) a compositor that has protocols I need (and accept that the tools won't work nicely in other compositors)
See also e.g. kicad.org/blog/2025/06/KiCad-a…
KiCad and Wayland Support
The KiCad editors (KiCad EDA)Sarah Jamie Lewis
in reply to Dan Ballard • • •@dan_ballard
Yes there has been a lot of work done in client libraries to bridge the complexity.
And there are tiers of compatibility. 80% of single-window apps can likely get by with just understanding the core wayland protocol and the "stable" extensions (which includes xdg-shell i.e. how to display a window)
They won't look nice, window decoration and mismatched cursor styles will make them standout from applications using a compositors preferred toolkit, but they will function.
mcc
Unknown parent • • •milas
in reply to mcc • • •Steam Deck uses a weird mix, Gamescope is Valve's Wayland compositor designed for running single Xwayland game, kind of like Wayback.
For ARM Mali GPUs, yes, surprising no one, the Linux driver situation is fairly chaotic. It very much depends on the generation, but for recent ones, there's proprietary/blob drivers (libmali) that come in X11/Wayland varieties but often have questionable Vulkan extension support. My experience was they could run a snapshot of Weston (the "reference" Wayland compositor) at some arbitrary point in time from when they wrote the drivers but were not really up to snuff otherwise. In the past couple years there's been a lot of progress and movement on Mesa-based OSS driver (pancsf) which is being driven by Collabora with support & blessing from ARM.