A set of merge requests were opened that would effectively drop X.Org (X11) session support for the GNOME desktop and once that code is removed making it a Wayland-only desktop environment.

Going along with Fedora 40 looking to disable the GNOME X11 session support (and also making KDE Plasma 6 Wayland-only for Fedora), upstream GNOME is evaluating the prospect of disabling and then removing their X11 session support.

Some concerns were raised already how this could impact downstream desktops like Budgie and Pantheon that haven’t yet fully transitioned over to Wayland. In any event we’ll see where the discussions lead but it’s sure looking like 2024 will be the year that GNOME goes Wayland-only.

  • taladarEnglish
    29·
    1 year ago

    need to be fixed by the compositor

    It is a Wayland issue that things like this need to be fixed per compositor. Honestly, what were the designers thinking?

    • Vilian@lemmy.ca
      1·
      1 year ago

      the compositor need to implement the option to change resolution, how could wayland(the protocol) dictate it?, it don’t have a feasible way to do it, what could help is less fragmentation, like using wlroot, but again wayland(protocol) don’t habe a way to dictate it

      • taladarEnglish
        1·
        1 year ago

        If they had kept the window manager concept, separating mechanism and policy they would have only needed one implementation for all the mechanisms.

        • Vilian@lemmy.ca
          1·
          1 year ago

          yes, they could have made the implementation from the start, and that is a valid criticism to wayland(i also agree), but we have wlroots now, and they are working very close with KDE(in one of the devs blog they even said about KDE being ported to wlroots in the future), except for gnome, every DE are working together

    • Communist@lemmy.mlEnglish
      1·
      1 year ago

      Why should it not be fixed by the compositor, exactly?

      As far as I see it, that’s a smart design choice, the issue is just that we needed a universal implementation, an x.org equivalent, and we now have that with wlroots, now that that exists, there’s no downsides to that approach, as far as i’m aware.

      • taladar
        1·
        1 year ago

        In what way exactly does that make it a smart design choice. It sounds like compositor implementers essentially have to work around the bad design choice by including a library and even then each compositor will have to update the dependency version for wlroots each time something needs to be fixed that breaks the wlroots ABI (or for containers, static linking,… just each time).

        • Communist@lemmy.mlEnglish
          11·
          1 year ago

          No, it sounds like compositors will use a library so that they don’t have to do a shitload of work that they’d have to do otherwise.

          …this is already how x.org works. You have to implement the x.org server, or create your own implementation of X11.

          The only reason you think your criticism doesn’t apply to X.org is because nobody updates X.org anymore… There’s no more breaking changes to be made because it’s a fundamentally broken, shitty protocol.