So let’s talk about this Wayland thing
So let’s talk about this Wayland thing
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 …
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.
The issue is that X was never a mature, feature-complete, stable project.
Looool. It was too stable, which means stagnation.
bloated hodgepodge of disparate and barely working patches.
You mean bloated protocol or bloated implementation? Because kwin_wayland is pretty bloated.
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.
Tying graphics server to audio server is very clean.
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
Wayland offloads a ton of stuff that was core to X11 (like input device handling) directly to the compositor.
Not exactly. Imagine if xorg was also desktop environment with own compositor and effects. That's what wayland compositor is.
For 1., the big issue is that there constantly are appearing new standards in display technologies. Two semi-recent examples are HDR and VRR, both of which X11 struggles with, and implementing those into X11 has been said to be painful by its developers.
Good read, provided context that I didn't have before as a newbie
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.
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.
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)
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 bloat blob driver instead of Mesa.
So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.
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.
It's working with Sway from a quick test:
swaymsg output DP-1 scale 1.7
But XWayland is blurry as expected (that's the big blocker, or all useful apps being ported to Wayland).
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
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...
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.
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)
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.
Why? Why plasma nailed own screensharing to audio server? There already are wayland extensions for this.
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, 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.