SUMMARY When locking the screen, I expect the display to go to sleep immediately and stay asleep unless I press a key to wake them up. While it does go to sleep, the screens wake back up immediately with the login prompt. If I press the escape key, they go back to sleep again and stay asleep properly. STEPS TO REPRODUCE 1. Lock the screen via the application menu OBSERVED RESULT The screen locks, goes to sleep, then immediately wakes up with the lock screen. EXPECTED RESULT The screen locks and goes to sleep. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 39 (KDE Plasma) (available in About System) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION
Could you restart your machine, reproduce the issue, and provide the complete output of `journal -b`? Thanks!
> When locking the screen, I expect the display to go to sleep immediately and stay asleep unless I press a key to wake them up Did it do this in the past? because that's not what it does by default, and you need to change some powerdevil settings to make this happen. Did you do so, and it worked in the past, but it stopped working recently?
(In reply to Nate Graham from comment #2) > > When locking the screen, I expect the display to go to sleep immediately and stay asleep unless I press a key to wake them up > Did it do this in the past? because that's not what it does by default, and > you need to change some powerdevil settings to make this happen. Did you do > so, and it worked in the past, but it stopped working recently? The only setting I changed was turning off auto-suspend for session. Screen energy saving is still on and set for 10 minutes and button events handling is still set to prompt when power button is pressed. I think it worked correctly back on Fedora 37 or Fedora 38, but I'm not sure. I did, however, notice today that it behaved differently from one of my laptops running Fedora Workstation (GNOME) and I vaguely recall it wasn't different before.
(In reply to Neal Gompa from comment #3) > The only setting I changed was turning off auto-suspend for session. Screen > energy saving is still on and set for 10 minutes and button events handling > is still set to prompt when power button is pressed. If that is the case, I don't think your screen should turn off immediately when you lock the screen, right?
It's not supposed to, no. And it doesn't anymore after updating to a new kernel, so it might have been a kernel bug. That said, I *want* a way to lock and sleep the screen in one go.
(In reply to Neal Gompa from comment #5) > It's not supposed to, no. And it doesn't anymore after updating to a new > kernel, so it might have been a kernel bug. That said, I *want* a way to > lock and sleep the screen in one go. Then I guess this should be turned into a feature request, since KDE doesn't seem to support this right now. @Nate, could you confirm?
It's already possible in Plasma 6. In the Energy Saving KCM, change the value of "When locked, turn off screen" to 0 seconds. Neal, does that do what you want?
(In reply to Nate Graham from comment #7) > It's already possible in Plasma 6. In the Energy Saving KCM, change the > value of "When locked, turn off screen" to 0 seconds. Neal, does that do > what you want? For me this doesn't work in plasma 6. The steps to reproduce are as follows: 1. Set "When locked, turn off screen" to 0 seconds for all three cases, on ac power, on battery, and on low battery 2. Lock the screen using the button in lock/logout widget Observed behavior: The screen turns black for a moment, but then immediately turns back on. Expected behavior: The screen turns off and stays off. This happens for me on latest neon unstable, with or without an external monitor plugged in.
Oh, I think I see something. Does it work if you set the duration to 1 second, rather than 0 seconds? That works for me, but 0 seconds fails.
(In reply to Nate Graham from comment #9) > Oh, I think I see something. Does it work if you set the duration to 1 > second, rather than 0 seconds? That works for me, but 0 seconds fails. That works, but that also has the effect of turning the display off during lock screen whenever there is 1 second without any output. I guess the feature requested here is different -- only change what happens when the user initially locks the screen, and add an option to immediately turn off the display.
I've got a downstream bug report that looks quite similar to this one: https://bugzilla.redhat.com/show_bug.cgi?id=2252467 It looks like it might be a kwin problem?
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 -3 daemon/actions/bundled/dpms.h M +6 -1 daemon/powerdevilaction.cpp M +6 -0 daemon/powerdevilaction.h https://invent.kde.org/plasma/powerdevil/-/commit/c58085b4ca3cf5456dd7cdfa4189d06b38a3e488 Didn't include this bug number in the commit message, an oversight when merging. Sorry! Either way, according to my understanding of this bug report, the above commit - via https://invent.kde.org/plasma/powerdevil/-/merge_requests/301 - fixes the behavior of 0-second "timeout when locked" in the way that makes the Expected Result of the original bug description work. Just make sure to set your timeout when locked to 0 (or another low value, depending on your preference).