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.
You must log in or register to comment.
Who even uses screensavers anymore? Just set the screen to turn off after a set amount of time.
a visible locking screen saver on idle workstations is a requirement in many places.
AFAIK screen locking is already possible and widely implemented; it’s just being handled by the display manager (? I think that that’s the right term). It’s just that you can’t install anything that provides a fancy animation, if I understand correctly.
deleted by creator
Yes and my screen locks when the screen turns off, don’t need useless graphics bouncing around.
With the increasing popularity of OLED displays, screensavers might make a comeback. Although I still think OLED displays aren’t worth it.
It’s not gonna be better than turning the screen off.
Don’t they typically do minor anti-burn in changes during idle, basically having a built-in screensaver? Still, an additional one could be nice for peace of mind.
Don’t they typically do minor anti-burn in changes during idle, basically having a built-in screensaver?
That’s what the display makers claim, in order to avoid too many customer complaints. In reality you’re still likely to get burn-in within a few years of monitor use, and when you ask for warranty support you’ll get denied claiming “you used the display wrong”.
Why? Burn-in hasn’t been an issue on my phone and that screen has been on for hours every day for the last three to four years.
Whatever Android does to protect against burn-in seems to work fine on modern OLED technology.
People don’t tend to keep phones for more than few years. On the other hand, I have LCD computer monitors that I still use over a decade later.
What really kills OLED displays is persistent static elements. These are common for desktop usage: persistent taskbar/dock, desktop wallpaper, window buttons, tiling, GUI elements and HUDs in gaming. All of these things significantly increase the chance of getting burn-in within a few years.
OLED fanatics suggest it’s all user fault, that people should just use a solid black background for their desktop wallpaper (ugly), have a auto-hiding taskbar (inconvenient) and limit time spent on programs/games (really). Basically rather than using the computer the way you want, you have to carefully handle it like an egg. An expensive egg at that, since OLED displays are still ridiculously overpriced (often costing more than equivalent TVs).
They try a lot of things, but they still burn in extremely quickly, much more so than any CRT ever did (which really never burned in in a consumer setting).
Oleds have built in hardware screen saver
jwz addressed this, actually, by responding, “Who hurt you?”
There’s already a wayland protocols extension in “testing”, called ext-session-lock-v1 [1]. Sway, river and other wlroots compositors already support it.
The ext-session-lock-v1 protocol is significantly more robust than previous client-side Wayland screen locking approaches. Importantly, the screenlocker crashing does not cause the session to be unlocked. [2]
Oh no!
Anyways…
Right so just installed xscreensaver - automatic blanking and locking is indeed broken BUT it does display all the pretty animations just fine! (at least on Sway)
Don’t really have time to mess around with it but maybe try figuring out which mechanism is used for screen locking in your environment (in Sway’s case it’s swayidle) and get it to start xscreensaver right before calling the real locker program?
BTW you can get xscreensaver-settings to come up by unsetting the WAYLAND_DISPLAY variable:env --unset=WAYLAND_DISPLAY xscreensaver-settingsPhilosophical BS: I don’t think it’s correct to say that Wayland doesn’t support screen savers, but rather that it doesn’t support XScreenSaver, or, more accurately, the mechanisms it uses for screen locking and idle-detection.
As others have pointed out, equivalent functionality has already been implemented and is used by various screen lockers. What appears to be missing is something to take this functionality, and display an animation instead of just locking the screen.
I noticed that all of XScreenSaver’s animations are actually separate binaries in /usr/lib/screensaver/ so we basically need a locker that speaks Wayland’s locking protocol, but also takes and runs those binaries in full screen mode.
Or maybe XScreenSaver’s dev can be convinced to add support once the protocols are stable?but rather that it doesn’t support XScreenSaver, or, more accurately, the mechanisms it uses for screen locking and idle-detection.
I think that’s the core of most X11 vs Wayland issues: the API changed and the system design has taken another approach, so the hacks that old software needed to use (because let’s be honest, the way XScreensaver implements a full screen override is kind of a hack) aren’t working anymore.
Screen locking in Wayland is actual locking, as in the system takes away control from the applicantions merely rendering to the screen, so the way the desktop works will definitely break most screensavers.
All in all the concept of a screensaver can still work without too much effort I think. Rather than let Mutter/Kwin lock the screen after a lack of activity, let the screensaver check if the user is idle (i.e. using the dbus API or by reading input through a daemon running as root), and make it spawn a fullscreen animation. When the user interrupts the screen through whatever means necessary, call the lock API of the Wayland compositor/window manager in use. Then wait a second (make sure the lock animation doesn’t unintentionally show open windows) and exit the fullscreen animation. I’m sure it can be made to work.
Other than rumors that HiDPI stuff works better on Wayland (which only affects me on my laptop since I was stupid enough to buy a 4k one), I’ve seen no real reason to switch away from X. It’s always just worked for me, and has since the 90s.
Maybe I’ll reevaluate again in another decade. Perhaps Wayland will be finished by then.
Its more secure. It is way better on multiple displays already. It is actually maintained. Windows are not just random things but there is actually a system behind it. Programs need manual portal permission to spy on you. No app can register your keystrokes or film your desktop.
“Dont ask yourself IF it works, but HOW it works” - Peter stuge
Did he say that because the answer to IF it worked was no?
He was referring to proprietary BIOSes that work for sure but suck. Coreboot on the other hand also works but doesnt suck
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.
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 offfor KDE Plasma andswaymsg "output * dpms off"for Sway.So every window manager now needs to implement tools to control power management ? That seems very uneconomical.
- “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.
- “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.
I personally actually prefer a not finished but clean system, rather than a “it works, somehow, I guess” system
no native network transparency
Xorg killed network transparency long ago.
On the server xhost +
On any other computer export DISPLAY=192.168.1.10:0 firefox
That works just as much today as it did back in 1997 when I first used that
