Marking as draft because I left some debug statements in there. In case you want to give it a try as well.
For automatic display turn-off, we now allow setting an idle timeoutwhen the screen is locked, down to 0 seconds. This makes sense whenthe session transitions from unlocked to locked, allowing the user toturn off the display at the same time as the lockscreen would appear.
Unfortunately, it doesn't work for a 0 second timeout. The issue isthat low timeout values also affect user interaction on wakeup,i.e. when trying to enter the password the user now has 0 secondsavailable to type their password. This prevents us from simplyremoving the check for >0 seconds when registering DPMS timeouts.
Instead, this commit splits the timeout when locked into two internalmember variables.
For the traditional "timeout when locked" value, we now apply a(hardcoded) minimum duration to allow uninterrupted authenticationwhen the lock screen is already active.
In addition, we introduce a new "timeout when activating lock" valuethat uses the configured value as is (more or less - applying anextremely short minimum may help prevent unintended behavior).This new timeout only gets used when switching from unlockedto 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.
Note for reviewers/testers: On Wayland, this seems to work as intended. On X11, there was already an issue when the screen locker activates via idle timeout and the display turn-off action gets fired before the startFade() signal, causing incorrect dimming to happen. This is still an issue after this patch, but I don't believe there's any regression either. It can be dealt with separately.
