It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
> The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session.
I think it's a reasonable design.
All screens lock together etc.
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
I'm imagining 2 processes:
1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process
2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt
When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.
If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.
None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.
There is also xsecurelock [1] by Google.
Argh. That would be the window manager, of course.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
Also this bug (and probably most other bugs xscreensaver has had over the years) wouldn't result in an infinite crash loop anyway.