Wayland does not support screen savers: it does not have any provision that allows screen savers to even exist in any meaningful way. If you value screen savers, that’s kind of a problem.

Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11.

But that means that accomplishing that task means not just writing code, but engaging with whatever passes for a standards body or design committee in the Wayland world, and that is… how shall I put this… not something that I personally feel highly motivated to do.

  • interdimensionalmeme@lemmy.ml
    link
    fedilink
    arrow-up
    10
    arrow-down
    3
    ·
    1 year ago

    So, we’re going to have to struggle with every single X11 feature until Wayland is done ? Still no native network transparency either ? Last I checked you couldn’t even control dpms monitor standby with xset and there was no equivalent.

    • lea@feddit.de
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      1 year ago

      Last I checked you couldn’t even control dpms monitor standby with xset and there was no equivalent.

      xset is xorg. The equivalent depends on your compositor, e.g. kscreen-doctor --dpms off for KDE Plasma and swaymsg "output * dpms off" for Sway.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      I personally actually prefer a not finished but clean system, rather than a “it works, somehow, I guess” system

    • feral_hedgehog@pawb.social
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago
      • “Screensaver” isn’t a feature of X - it’s functionality provided by XScreenSaver which uses X mechanisms to detect user inactivity, lock the screen and display an animation.
        Equivalent mechanisms exist in Wayland, but XScreenSaver doesn’t have logic to interact with them. This can be solved by either teaching XScreenSaver how to talk to these new mechanisms (difficult as it was developed for X from the ground up) or implementing something new.
      • Network transparency already exists (and has for some time) in the form of waypipe.
      • xset isn’t a feature of X - it’s a utility to control it. Since Wayland compositors aren’t X, it makes sense for them to be controlled differently.