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 …

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 …

  • BaumGeist@lemmy.ml
    175·
    1 year ago

    1. Stagnation isn’t 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.

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

    • verdigris@lemmy.ml
      141·
      1 year ago

      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.

    • 0x0@social.rocketsfall.net
      62·
      1 year ago

      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!

      • jack@monero.town
        41·
        1 year ago

        Can someone debunk this please? It feels like something is overlooked here

        • chaorace@lemmy.sdf.orgEnglish
          2·
          1 year ago

          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 ↩︎

          • jack@monero.town
            1·
            1 year ago

            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.