Moving Screenlocker into KWin

It makes sense to move the screenlocker into KWin as that would give the window manager and compositor more control about the locked screen. Only if the Compositor knows that the screen should be locked it can ensure that no other window gets on top of the screenlocker or that private data leaks through. More info about the idea can be found in this Blog Post.

Current Situation

The screenlocker is part of KRunner. The actual screenlocker(~saver) is run in an own process "kscreenlocker" to prevent screen unlocking when krunner crashes. The screenlocker has an own window and tries to keep it on top of the X Stacking Order (which is not always possible). Additionally it grabs keyboard and mouse (which is not possible if e.g. a window menu is open).

Screenlocker in KWin

With Compositing

When Compositing is active there is no need to have a window to do the locking. The lock itself can be done in an effect and core. KWin core needs to perform a mouse and keyboard grab (not needed on Wayland as all input events are routed through KWin). As long as the screen is locked and no user interaction the compositor just stops repainting (no window content is shown).

When there is user interaction the unlock dialog has to be shown. This should be done through an Effect. The effect can take care of disabling the rendering of all windows except the unlock dialog (which is created by the effect) and the Effect can request to paint the screen with background first ensuring that everything is blacked out.

Also screensavers (or Plasma sreensaver) can be controlled by the effect. The effect creates the screensaver window and ensures that this one is rendered and all other windows aren't.

As long as the screen is locked the core may not suspend compositing.

This compositing architecture does not rely on X11 and will work on Wayland, too!

Without Compositing

Without Compositing the same borked situation is present as with the old architecture in KRunner. Best is to just keep it completely unchanged (but moved to KWin). As long as the screenlocker is active, KWin may not start compositing.

Security

If the screenlocker is moved into the KWin process there is the chance that KWin crashes which would stop the locker. The simple solution would be to follow the old architecture of having an out of process which would make everything impossible which is discussed above.

If KWin crashes without restarting privacy is leaked but the system is hardly useable due to missing window manager. This situation can savely be ignored as a corner case as KWin normaly restart.

If KWin crashes with restarting (default) KWin should reastablish the lock. How can this be achieved? Maybe KDisplayManager could be queried whether the screen is locked? Maybe KWin could use a lock file (problem: lock file could be deleted by the same malicious software which killed kwin)?

If another window manager is started KWin would be stopped and the locker would be removed (as other window managers do not support this feature). Possible solution: break ICCCM2.0 support by not honouring replace.

Screensavers without Locking

No valid use case: should no longer be supported.