Why doesn't it? Well, I suppose the designers of Wayland have no joy in their cold, black hearts simply do not value screen savers.

I suspect that some day someone will graft screen saver support onto Wayland. I have thoughts on this.

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.

However, as I am the world's foremost expert on screen savers on Unix-like operating systems, here are a few simple admonitions for young and old.

Under macOS, old-school X11 and Wayland, the graphical boot sequence is basically the same, and uncontroversial:

1. Kernel runs init;
2. Init runs a "graphical session", which sets up the frame buffer;
3. The session displays a login prompt;
4. After authenticating, the desktop environment is launched (Finder, etc.)

When you are logged in and the screen is locked, things go differently. Under macOS, the same "graphical session" process that managed the login window handles locking and authentication. Importantly, if this program crashes, you are logged out.

Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11.

So here's how locking and blanking should work under Wayland. I am not terribly familiar with Wayland or its terminology, but I can guarantee that if it diverges from this outline in any particular, grave design mistakes have been made and must be corrected.

There are three idle timeouts at play:

1. Blank after: when to blank the screen or run a graphical saver;
2. Lock after: when to require a password to return to the desktop (must be >= blank after);
3. Power save after: when to power down the screen (must be >= blank after)

How those interact is fairly obvious. This logic should be embedded in the main loop of the session manager:

if not blanked {
    if idle >= power save after {
        power down
    } else if idle >= blank after {
        launch screen saver
    }
} else if user activity {
    if powered down {
        power up
    }

    if blank start time < lock after {
        kill screen saver
        unblank
    } else {
        prompt for password
        if verified {
            kill screen saver
            unblank
        } else if was powered down {
            launch screen saver
        }
    }
} else if powered up and idle >= power save after {
    kill screen saver
    power down
}

The meat of it, of course, is "launch screen saver". Under macOS, how that works is, the system instantiates a configured subclass of a ScreenSaverView window sized for each monitor and tells each of them to start animating. I assume that Wayland-heads will want to do this by sending DBus messages to some daemon that has registered itself as "I am the screen saver".

When it it time to start drawing, that screen saver manager just needs to know set of rectangles into which graphics should be drawn, whether that's a set of window IDs, or geometry specifications, or whatever.

Things to keep in mind:

• The display manager should prevent any other program from drawing to the screen while it is blanked or locked: no dialogs, popup windows, notifications, etc. The only thing that should be allowed to draw to the blanked screen is the screen saver. (Make it an option if you must, but I assure you that for every person who likes it that a dialog box can pop up on top of their screen saver, there are a thousand more who consider that a security bug.)

• Enable an option to slowly fade the desktop to black when blanking, interruptible by user activity.

• Enable an option to slowly fade from the screen saver to the desktop when unblanking, interruptible by keys and clicks but not by mere mouse motion. Both of these options are probably easier to implement in the display manager than in the screen saver daemon, but either is fine.

• Bear in mind that the screen saver daemon might choose to run the same display mode on more than one screen; or a different one on each; and might choose to stop one display mode and start another after a timeout while the screen remains blanked. It may do this by forking sub-processes, so any screen-access authorization must be inheritable.

• Make it possible for for the screen saver to access the current desktop image, or the desktop image as it appeared pre-blanking. Many people rightly consider this a security exposure and leave it turned off, but many others enjoy it that their screen savers can hack their desktop image. It is a popular feature.

• Do not consider a single pixel of mouse motion to be enough reason to power the screen back on. People who live near cats, trucks or slamming doors do not appreciate that.

Good luck! You'll need it.

Previously, previously, previously, previously.