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.

  • Vilian@lemmy.ca
    3·
    1 year ago

    thy gamescope(that run on steam deck) i think it can scale, if yes, so it’s an implementation issue, that need to be fixed by the compositor

    • taladar@sh.itjust.worksEnglish
      19·
      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

        • taladar@sh.itjust.worksEnglish
          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.

      • 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@sh.itjust.works
          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).