Our Plasma workspace has offered the feature to lock the screen when resuming from suspend for a long time. Ideally the screen gets locked right before the system goes to suspend to ensure that the screen is properly locked when the system wakes up.
The process was controlled by powerdevil: when powerdevil decided that it should suspend the system, it invoked the lock screen to get the screen locked. But this has drawbacks. For example the screen locker doesn’t know that the system is going to suspend. Neither does powerdevil know when the screen is fully locked (the lock process includes multiple stages and the actual lock is hold before the screen gets blanked). Also it only works with powerdevil, if one suspends the session in a different way (e.g. through systemctl suspend) the screen doesn’t get locked. The worst drawback was that sometimes it was still possible that the system woke up and expose the session for a split second as the screen locker has no way to indicate to the system to wait with the suspend till everything is settled.
With the upcoming Plasma 5.2 release this will significantly improve by leveraging functionality provided by logind. The lock screen on resume functionality is moved from powerdevil into the screen locker. This already means that the screen locker has a more complete picture of what is going on and allowed us to streamline the settings: whether the screen locks on resume is now found in the same configuration module as all other screen locker related settings.
The most important change is that we are now able to ensure that the screen is locked before going to suspend. For this the screen locker holds an inhibitor lock. When the screen is going to suspend, the screen locker is notified by logind, can start the lock process and remove the inhibitor lock once the screen is properly locked. This means under normal condition the screen will be locked before going to suspend (of course a timeout in logind could be hit if everything takes too long or if the screen cannot be locked).
Obviously this will only work if the system is suspended through logind, which powerdevil does if logind is available. So our users who use logind get an improved experience. For our users who do not yet use logind nothing changes: powerdevil notifies the screen locker that it’s going to suspend and the screen locker starts the lock process. This obviously has the same limitations as described above.
Is logind also invoked when suspending via terminal by issuing pm-suspend or systemctl suspend?
I don’t know for pm-suspend, but systemctl suspend: yes.
So does this mean Plasma now requires SystemD?
oh nevermind I apparentlys skimmed the last paragraph…
Great. 🙂
I noticed this effect too, since I upgraded to OpenSUSE 13.2. It is almost always and is usually something like half to one second, i.e. sometimes long enough that I can easily see which windows were open and read a few lines of text, email subjects or things like that. I think I never saw this before.
I have no idea, but may this delay depend on other things, like e.g. the time the WLAN connection takes or the time the machine needs to detect the DVD which is currently in the drive ?
If you have a chance to improve this behaviour also for the unreliable case for KDE 4.x, even if it’s a hack, it would be nice. 🙂
sorry, no chance for a backport to KDE 4. It’s too invasive, using too many Qt 5 code elements.
Hmh, speaking about the screen locking – will it interact with power management / activities in future? The problem is, when I’m watching a movie, I can have an activity and/or power management setting for the screen not turning off, but I can’t deny the screen locking (at the moment).
screen locker has an inhibition API – video players should use it.
In KDE 4 (I didn’t test KDE 5, yet) screen locker wouldn’t get activated on suspend if a desktop effect such as desktop grid or present windows was active. Is this fixed in KDE5/Kwin5/Plasma5?
No, that’s a general restriction of X11 and will be fixed with Wayland.