- cross-posted to:
- linux@lemmy.world
- kde@lemmy.kde.social
- cross-posted to:
- linux@lemmy.world
- kde@lemmy.kde.social
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 …
deleted by creator
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.
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.
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.
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.
deleted by creator
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.
deleted by creator
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 https://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.
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
deleted by creator
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?