[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 Nate Graham changed: What|Removed |Added Version Fixed In||6.0 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 Jakob Petsovits changed: What|Removed |Added Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/c580 ||85b4ca3cf5456dd7cdfa4189d06 ||b38a3e488 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakob Petsovits --- Git commit c58085b4ca3cf5456dd7cdfa4189d06b38a3e488 by Jakob Petsovits. Committed on 05/01/2024 at 02:39. Pushed by jpetso into branch 'master'. actions/bundled/dpms: Handle very short timeout-when-locked better 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 doesn'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. M +52 -16 daemon/actions/bundled/dpms.cpp M +8-3daemon/actions/bundled/dpms.h M +6-1daemon/powerdevilaction.cpp M +6-0daemon/powerdevilaction.h https://invent.kde.org/plasma/powerdevil/-/commit/c58085b4ca3cf5456dd7cdfa4189d06b38a3e488 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #11 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/301 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 dmatteo...@gmail.com changed: What|Removed |Added CC||dmatteo...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #10 from fanzhuyi...@gmail.com --- Alternately, how about having a separate checkbox saying immediately turn screen off after lock? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 fanzhuyi...@gmail.com changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=477641 CC||fanzhuyi...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #9 from Natalie Clarius --- Ah, I see the problem. Yeah, it probably makes sense to go back to screen off after some idle time after input in locked state, though I don't think we'd need to make this timeout configurable. I think just setting it to 1 minute in that case would capture the users's intentions well enough. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #8 from Jakob Petsovits --- And sorry for conflating "sleeping" with "turning off screen" in the comment above. I meant the latter. Same idea though. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #7 from Jakob Petsovits --- (In reply to Natalie Clarius from comment #6) > Why do you think we need two different settings? Imo setting it to 0s should > turn it off immediately when going unlocked -> locked but also turn on again > immediately once there is input in already locked state. Let's say that 0s is the configured timeout for sleeping when the system transitions from unlocked to locked. So it goes to sleep immediately after locking. We have also established that we can't (shouldn't) use 0s as a timeout after user input when already locked. I think it's also clear that if the user stops typing / doesn't manage to log in, there should still be a timeout (>0s) for putting the system back to sleep. We can call this a "setting" or anything else, and it doesn't have to be user-configurable, but it seems clear that another timeout value is needed apart from the original (0s) configured one. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #6 from Natalie Clarius --- Why do you think we need two different settings? Imo setting it to 0s should turn it off immediately when going unlocked -> locked but also turn on again immediately once there is input in already locked state. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #5 from Jakob Petsovits --- So... two different settings? Or keep one setting, but we apply a hardcoded lower bound (say, 10s) for the "already locked, woken up on user input" case? I guess we probably only want to expose one timeout value, to avoid bombarding the user with mostly unnecessary information. (Exposing both regular and "when locked" timeouts is arguably on the more overkill side of things already.) -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #4 from Natalie Clarius --- Imo ideally it should be possible to configure immediate turn off when the screen goes from unlocked to locked, but not have the turning off fire when the screen already is locked and now receiving input. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #3 from Jakob Petsovits --- The fix was simple, removing the check for > 0s in the code (https://invent.kde.org/plasma/powerdevil/-/blob/3de931d603796c8d245f775a50f5e178e0564d93/daemon/actions/bundled/dpms.cpp#L191) will do the trick. This made the screen turn off immediately after locking. Plot twist: When I wanted to unlock the screen, I wasn't able to anymore because PowerDevil would immediately activate the dim-and-turn-off effect, which apparently also prevents input and caused lots of flickering when I just wanted to enter my password. Maybe it's not such a great idea to let people configure immediate turn-off? Should we assign a non-zero lower bound? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 --- Comment #2 from Jakob Petsovits --- Can reproduce as well. If I set the value to 10 seconds however, or even just 1 second, the feature works and the reproduction steps result in a turned-off screen. There must be some kind of race condition where locking the screen triggers a user activity signal and the turn-off timer doesn't get reset, or something of that sort. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 476962] Screen does not respect "when locked, turn off after X seconds" setting
https://bugs.kde.org/show_bug.cgi?id=476962 Nate Graham changed: What|Removed |Added Component|kcm_powerdevil |general CC||j.acco...@petsovits.com, ||m...@ratijas.tk, n...@kde.org Summary|Screen does not turn off|Screen does not respect |immediately after locking |"when locked, turn off ||after X seconds" setting Product|systemsettings |Powerdevil --- Comment #1 from Nate Graham --- Can reproduce. -- You are receiving this mail because: You are watching all bug changes.
