So let’s talk about this Wayland thing
(pointieststick.com)
from Vincent@kbin.social to linux@lemmy.ml on 18 Sep 2023 10:33
https://kbin.social/m/linux@lemmy.ml/t/465738
from Vincent@kbin.social to linux@lemmy.ml on 18 Sep 2023 10:33
https://kbin.social/m/linux@lemmy.ml/t/465738
Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite …
threaded - newest
I want to switch to Wayland. I try it every month to see if it is working with my system and so far it is not.
Ubuntu 23.04/Nvidia 3080/Steam. It use to work with the old big picture mode but when steam went to the new one, Wayland broke for me.
That’s weird. I thought Steam doesn’t support Wayland at all and runs using XWayland.
Gamescope makes the experience a lot better with steam at least for me in swaywm. I experimented with running each game in gamescope using launch options but with gamescope’s mediocre support of the steam overlay some multiplayer invite stuff doesn’t work correctly. Running steam in bigpicture within gamescope pretty much solves all these issues and seems to improve performance too.
To be fair you probably use
bloatblob driver instead of Mesa.Good read, provided context that I didn't have before as a newbie
Let’s not, megachads.
Stagnation isn’t always evil, it’s just part of tech. Once tech solves the problem it set out to, it should stagnate. Adding more bells and whistles makes things better less often than it makes them bloated and more prone to breaking. On the flipside, software that hasn’t changed much other than bugfixes and security patches is the backbone of a loooot of our tech infrastructure. Edit: @SkyeStarfall@lemmy.blahaj.zone provides an excellent refutation, with counterexamples showing where lack of new features is hurting X11 here (direct link broke for me on lemmy.ml, hence the redirect)
I fail to see how the architectural difference fundamentally solves the issue of changes breaking compatibility. Now instead of breaking compatibility with the server, you’re “only” breaking compatibility with the compositor. But that’s okay because at least there are other compositors that fulfill this use case… oops switching to that compositor broke 3 of your other apps, well lets try another! … and now my pc won’t communicate with my GPU… well, we can always… and so on and so on.
Not saying that wayland is bad nor that X is better, but these are the two most common “cases against X/for wayland” that I hear and I just don’t buy it. As much as I argued against it, I love trying new and different software and eking every last bit of performance out of my 8 year old PCs, I can’t wait to give Wayland a try and see if there’s a noticeable difference… I just wish these two arguments would go away already
As I understand it, Wayland offloads a ton of stuff that was core to X11 (like input device handling) directly to the compositor. The end result is every compositor handling things differently. Compare something like i3 to Sway. Sway has to handle input, displays, keyboard layouts, etc directly in its config. If I switch to Hyprland I then have to learn Hyprland’s configuration options for doing the same. Meanwhile, switching from i3 to dwm requires only setting up the WM to behave how I want - no setting up keyboards, mice, etc. It just feels clunky to work with Wayland compositors, frankly.
Also when something breaks in Wayland the fix is almost always hard to find or incredibly obscure because the fix isn’t for Wayland- it’s for the compositor. If your compositor isn’t popular then good luck!
Can someone debunk this please? It feels like something is overlooked here
They got all of the basic facts right and their general experience mostly mirrors my own, though in my case the majority of problems encountered apply to Wayland in general and are rarely compositor-specific. That is to say that I can usually Google “[APP]” [FEATURE] not working “Wayland” and find people from a variety of different Wayland compositors all experiencing the same thing[^1]. Maybe I just got lucky when I chose my specific compositor?
In fact, despite being on Wayland for about a year now, the only compositor-specific issue I’ve ever encountered is a broken controller configuration overlay when using Steam’s Big Picture Mode. It’s actually super frustrating because I have absolutely no idea if it’s an issue specific to my compositor, wl-roots, or something unique about my configuration. All I really know is that it works correctly if I launch Steam in a nested gamescope compositor, so it’s not a bug in the protocol nor xwayland.
[^1]: Some recent examples: broken Steam Controller cursor, busted SDL in TF2, Invisible Emacs cursor
Thanks for sharing your experience. If the majority of issues are Wayland-wide right now instead of compositor-specific, then that is good in my opinion. These issues get fixed once at the protocol level and are then solved for everyone. Compositors should principally just work, given that they implemented the protocol correctly.
Not all protocol-level fixes are implemented. Example: protocol-level screen sharing. There is extension for this, but kde and gnome use pipewire instead. Basically it is X11 all over again, but worse.
Why are they not using the protocol-level solution, is the pipewire way just simpler to implement? Also, why is the screen sharing fix just an extension and not part of the core protocol?
GNOME and KDE both support the desktop-agnostic xdg-desktop-portals which provide general desktop APIs and that’s what most DEs are now converging. The portals including screensharing, input emulation and much more. The problem is that sway/wlroots doesn’t want to support it as they’re somehow vehemently against a D-bus dependency
Dunno. wlr-export-dmabuf-unstable-v1 exists for a while. And wlr-screencopy-unstable-v1. Last one implemented in Sway and Mir.
Kde uses kde-zkde-screencast-unstable-v1 which requires pipewire for some reason and Gnome seems to use unregistered extension.
Not exactly. Imagine if xorg was also desktop environment with own compositor and effects. That’s what wayland compositor is.
The issue is that X was never a mature, feature-complete, stable project. It was always a hideous and bloated hodgepodge of disparate and barely working patches. The entire point of Wayland is to do exactly what you say tech should do: solve the particular problem (graphics server) well and cleanly, and limit itself to a definable set of features so it can actually reach that point of stability.
Looool. It was too stable, which means stagnation.
You mean bloated protocol or bloated implementation? Because kwin_wayland is pretty bloated.
Tying graphics server to audio server is very clean.
Stagnation here specifically does mean that nobody is making bug fixes or security patches anymore. Xorg is abandoned, kaput, a former software project.
The new architecture allows developers to fix one thing without accidentally breaking 3 others.
Then the problem is that it’s abandoned, not that it has stagnated (which can also be phrased as “stabilized” depending entirely on context and the speaker’s/author’s personal feelings about the project). Once again, I’m not saying that Xorg is good, but that particular critique needs to stop; it’s major flaw is that even the “maintainers” are sick of it and want it to die, not that it has ceased major developments.
Even the article acknowledges this:
But it also falls into the “Bells and whistles” side of the critique immediately after:
and it even starts of explaining the problems with X by saying it’s in “maintenance mode.” I couldn’t care less about new features, the Pareto principle implies 80% of users don’t need new features regardless of how much dopamine they get from seeing the marketing hype. “Maintenance mode” isn’t a bad thing, it’s a good thing. Abandoned projects that most GUIs still rely on is a disaster waiting to happen.
That’s an extremely bold claim, and vague, with no actual examples. Do I take it on faith that changing code can break things with X? Yes, but I, having worked with code, just assume that’s what happens to all software. Do I believe that Wayland has found a way to do away with that problem of software architecture (and not necessarily protocol architecture)? Not unless they’ve somehow found a way to compartmentalize every single module such that every aspect is fully isolated and yet has interfaces for every potential use case that could ever be dreamed up. Any devs in the comments want to pipe up and let me know how that endeavor has worked for them in past projects?
The problem is not the code per se, but that we can’t add stuff anymore that doesn’t somehow break the core protocol. The plain fact is that we’ve been tacking on things to X11 which it was never designed to do for decades and we reached a breaking point a while ago.
Stuff like multi-DPI setups are impossible to implement in X11’s single-framebuffer model; security on X11 is non-existent, but we can’t retroactively fit any kind of permissions on the protocol as that breaks X11 applications that (rightfully) assumed they could get a pixmap from the root window. There’s so much more, just take look at www.youtube.com/watch?v=RIctzAQOe44
By all means, feel free to start working on it!
All the people who developed Xorg for 20+ years decided that creating and working on Wayland was a better use of their time. But I’m sure you know better…
The problem isn’t that Xorg is spaghetti code (it’s pretty good for a large C project, imho). The problem is that the X11 protocol was designed to expose the capabilities of 1980s display hardware.
Stop putting words in my mouth. I never mentioned spaghetti code, and i said nothing about being better or smarter than either Xorg or Wayland devs
You said that Xorg being abandoned is the problem. How should we interpret that, other than a criticism of the decision-making process of the devs?
Wayland will become a spaghetti too, unless you do “compositorhop” because one compositor is not complete and need to use another, idk if this would be a good idea
I have to use Slack for work and screen sharing doesn’t work when I’m using Wayland.
I started running OBS with a virtual camera to do screen sharing. It is so much nicer to manage sharing with OBS than with Slack/Google Meet/Discord.
Oh, never heard of this, I will check it out thx.
Oh, that sounds like an interesting idea. Currently stuck with teams at work. Screen sharing does work under wayland. But definitely going to try this.
Try using XWayland video bridge. It should allow any XWayland apps to use screen sharing. Unfortunately most distros either don’t ship it yet or ship broken versions but you can download nightly Flatpaks from Gitlab CI
I’m not sure why, but every time I use XWayland Video Bridge (installed as of about 2 days ago so it should still be pretty new), I just end up with a black screen being broadcasted - not sure what could be causing that.
Thx!
Don’t let Slack launch at startup. As long as it launches after pipewire - everything works. Your can also restart it to fix sharing issue, but that can be a birch if you already started a call.
Oh, thx for the tip!
Is there a way to control the launch order? I suppose you could also find a script that waits for a given process to be responsive before launching another, but I’m not sure where I’d insert that either.
(I’ve been using Ubuntu mostly out-of-the-box so far and just now started having the time and energy to start learning about and fiddling with the internals)
I’m not sure that would work. Pipewire probably starts via system (just takes a while to become functional) and slack is started by KDE. I guess you could just add a delay to slack’s start, but I just start it by hand.
Starting by hand is fine and I do it with just about anything I need anyway (though I suspect there is still some startup bloat I’ll need to sort out, if I don’t set up an entirely new system somewhere down the line), but don’t underestimate my compulsion to automate what I can (or at least know how to).
I’m a sucker for automation for automation’s sake :D
If it launches via a systemd service, you can perhaps edit the file such that it depends on Pipewire before it launches.
Or disable the built in startup support and create your own service that does the same.
Why? Why plasma nailed own screensharing to audio server? There already are wayland extensions for this.
Pioewire handles audio and video pipelines between applications.
So why Wayland instead of pipewire at all?
Because Pipewire only handles and understands media streams, so it can stream the output of a window or the whole desktop, but only because the Wayland compositor has already composed the windows and other data it gets from the application to a visual and hands the final result to Pipewire.
Which goes back to oroginal question. Why pipewire if there are already wayland extensions?
Because it is convenient for programs to use Pipewire for screensharing, as those programs can then also use the same Pipewire support for all their audio and webcam needs. Also Pipewire is good at multiplexing the various media streams.
And what developers will hammer their apps to one sound server implementation? What is convenient here? Loosing interoperability? You always can use Wayland for screensharing, ALSA for sound and V4L2 for webcam.
For the multiplexing, as I mentioned.
A V4L2 camera can only be opened by a single application at a time, but if that application is Pipewire, then Pipewire can allow multiple applications to make use of it simultaneously. Same thing with ALSA, it’s the reason sound servers exist at all, though I suspect you’re already familiar with that.
I also hear that ALSA has some support for multiple applications per device nowadays, though I understand it is much less pleasant to use than a fully featured sound server.
What? Nowdays? Do you live in 2005?
To be fair v4l2 sometimes needs additional processing to allow multiple processes to use same webcam at same time. At least for those applications who use libv4l because I’ve seen mentions that this is because for some reason libv4l checks that camera is not in use.Reading the fucking manual suggests that V4L2 is totally fine with multiple programs using same webcam without any workarounds, just only one program can set resolution and other stuff.
EDIT: found mentions of dmix in 2004. Will I find mention from 2003 to finish with round number? Also hardware mixing was in ALSA since creation, but it required hardware(thanks, cap).
I live in a time where I don’t need to edit config files by hand to allow using multiple applications with the same audio output, since I use a sound server. If you’re willing to do it by hand, then by all means continue. Though it does seem that ALSA has had support for automatically setting up dmix since 2005, after PulseAudio was released.
I also don’t know if resampling and the like is automatically handled when using dmix, but perhaps you can tell me that, since it sounds like you have experience with it?
How about we keep a good fucking tone. Yes, that’s great. However my experience is that programs all want to set those properties without a way to disable it, so in practice it doesn’t really matter.
Yeah, as you mention hardware mixing used to be an option, but AFAIK hardware generally hasn’t supported that for a long time.
Another reason to use Pipewire is to enable sandboxed access to multimedia devices, for use with things like Flatpak or Snap.
You don’t need to. It just works out of box.
And after JACK. And PulseAudio development started after JACK was released.
Eiher by dmix or by libalsa since I never had issues with samplerate.
Not to offend you, just saying that reading manual is one of the best ways to get information.
For some reason. I don’t remember having such issue, but I also don’t remember using same webcam in two applications for sure, but I think I used v4l2loopback “webcam” in VLC and chromium at the same time.
Well, /dev/videoX can be forwarded to sandbox. Snap and Flatpak are not designed to be a sandboxes.
Sorry I forgot to reply. Better late than never.
FYI
Many older sound chips had hardware support for mixing multiple streams, and so the alsa drivers for those happily allowed multiple apps to open and write to the /dev/snd/whatever device. Life was good and people got used to doing it this way.
Nowadays (since like 2000 lol), sound chips generally expect a single pre-mixed stream. So the sound device for those is exclusive open. The libalsa devs made it possible to have the first app to open the sound device act as the sound server for every other app that tries to open it later. But it was complicated and fragile and just a bad idea in retrospect.
That has nothing to do with Slack’s screen sharing issues. Screen sharing was broken due to Electron bugs and it’s fixed in Slack 4.34.
I’d argue lazy choice of wrapping your website inside chrome instead of building a native app is Slack’s issue.
I also wonder whether Slack fixed it or just waited for Google to fix it since Slack seems to only have UI designers and no actual devs on their team. They keep pumping out useless UI changes while actual bugs take years to fix.
Many Electron maintainers are Slack employees. They’re contributing upstream more than most other companies that use Electron, especially compared to their size.
Could you name a couple? Genuinely interested to check out their contributions.
Also, I just updated to 4.34.119 and screen sharing is still completely broken. As is typical with Slack.
Great article. I’m currently still on X because Plasma 5 doesn’t handle fractional scaling well. As soon as that changes (Plasma 6?) I’ll be jumping over to Wayland.
For me it’s Barrier/Input Leap which keeps me stuck on X. Still waiting for a solution there then I’m moving over.
Note that there’s now a solution for this in Wayland compositors that support the InputCapture portal. This should work on the latest (or next? not sure) version of Input Leap and GNOME 45 (which launches as part of Fedora 39)
X handles fractional scaling terrible as well lol. Has caused terrible tearing and framedrops for me on a Framework 13.
And this is what I am talking. Fragmentation. Fractional scaling extension exists in wayland protocol for a year of more.
Is fractional scaling in Wayland really working now? I tried it a while ago and everything was blurry mess.
I just tried this and it was blurry until I logged out and back in!
Just tried it on my laptop and xwayland apps are still blurry mess, even after restart. However, all apps I use now has Wayland support that can be enabled with some flags or environmental variables, so they are actually usable now with fractional scaling. Finally I can use my laptop with 175% scaling, which is much more comfortable than 200% scaling.
In display settings check the box to allow x11 apps to scale themselves instead of the compositor. Your cursor will still be blurry but the app content itself will be fine. A few apps like steam won’t scale without some kind of launch flag though.
I don’t see this option. I didn’t even see the option to set fractional scaling without enabling experimental flag from command line.
I assumed you were on KDE since the dev who wrote the blog post was talking about KDE Wayland but are you on gnome? Gnome"s fractional scaling implementation isn’t as good as KDE’s.
It’s working with Sway from a quick test:
But XWayland is blurry as expected (that’s the big blocker, or all useful apps being ported to Wayland).
We need another display system. Something more dev friendly and more desktop agnostic.
I seems Wlroots is designed to be server agnostic (despite the name), if it is bound to a new display server many apps should be available.
Ok, breaking up X11 to Wayland was good as it was so big. Now, lets look at the Linux kernel…
I’d run Wayland on my main PC but Nvidia drivers don’t support Wayland too well, when they do I’ll switch over but for now I’ll wait
I’m gonna give it an honest go once KDE Plasma 6 hits the arch repos.
I also want to try COSMIC when it comes out apparently it’s got Wayland support built in and looks pretty good imo