Skip to content

actions/bundled/dpms: Handle very short timeout-when-locked better

BUG: 476962 BUG: 477641

For automatic display turn-off, we now allow setting an idle timeout when the screen is locked, down to 0 seconds. This makes sense when the session transitions from unlocked to locked, allowing the user to turn off the display at the same time as the lockscreen would appear.

Unfortunately, it didn't work for a 0 second timeout. The issue is that low timeout values also affect user interaction on wakeup, i.e. when trying to enter the password the user now has 0 seconds available to type their password. This prevents us from simply removing the check for >0 seconds when registering DPMS timeouts.

Instead, this commit splits the timeout when locked into two internal member variables.

For the traditional "timeout when locked" value, we now apply a (hardcoded) minimum duration to allow uninterrupted authentication when the lock screen is already active.

In addition, we introduce a new "timeout when activating lock" value that uses the configured value as is (more or less - applying an extremely short minimum may help prevent unintended behavior). This new timeout only gets used when switching from unlocked to locked, and is replaced by the regular "timeout when locked" thereafter until the session gets unlocked again.

Suspend/resume handling receives some extra care to behave well. Unlocked timeouts also apply a minimum duration for extra safety.


Extra commit to fix a pre-existing (but related) issue:

actions/bundled/dpms: Less fragile code for pre-turn-off fading

Simplifies the code for better readability.

Also solves an issue on X11 when an activating screen locker reduces the idle timeout, or for idle timeouts shorter than the hardcoded 5 second fade-out grace period. In either of these cases, both the fade and action timeouts would be signaled immediately after one another, but in the wrong order. The observed effect was that the screen turned off first, the user moves their mouse to avoid locking, and the screen comes back on but fades out anyway.

The refactored version avoids these kinds of race conditions by simply connecting the turn-off action to the screen helper's fadedOut signal, or in case of Wayland, directly to the timeout like before. No hardcoded fade-out times are necessary anymore.

Edited by Jakob Petsovits

Merge request reports