"I would have to follow up with you on that, Mr. Gomert."
Previously, previously, previously, previously, previously, previously, previously.
"I would have to follow up with you on that, Mr. Gomert."
Previously, previously, previously, previously, previously, previously, previously.
The 6.00 refactor of the X11 XScreenSaver daemon has so far proven to be very stable and secure! The bugs fixed in this release are relatively minor. However:
Sadly, due to recent catastrophic decision-making on the part of certain Linux distros, I was forced to add the following section to the XScreenSaver manual:
THE WAYLAND PROBLEM
Wayland is a completely different window system that is intended to replace X11. After 13+ years of trying, some Linux distros have finally begun enabling it by default. Most deployments of it also include XWayland, which is a compatibility layer that allows some X11 programs to continue to work within a Wayland environment.
Unfortunately, XScreenSaver is not one of those programs.
If your system is running XWayland, XScreenSaver will malfunction in two ways:
- It will be unable to detect user activity in non-X11 programs. This means that while a native Wayland program is selected, XScreenSaver will think that you are idle, and may blank the screen prematurely.
- It will be unable to lock the screen. This is because X11 grabs don't work properly under XWayland, so there is no way for XScreenSaver to prevent the user from switching away from the screen locker to another application.
If you are aware of some way for XScreenSaver to reliably detect user activity under Wayland, do let me know. Maybe there is some dbus/systemd signal that I have missed?
Now that the XScreenSaver 6.x daemon has been sandboxed and massively reduced in size, it might be plausible for someone to rewrite xscreensaver.c to speak Wayland instead of X11, to run inside the Wayland compositor, and then to launch the X11 programs xscreensaver-auth and xscreensaver-gfx as needed. But that someone will not be me.