(This is basically the 5 equivalent of https://bugs.kde.org/show_bug.cgi?id=311116 ) I want a way to blank the screen in the screenlock on demand, via a shortcut or button. Use cases: 1) You're watching the TV and accidentally nudge the mouse - the laptop screen now glows brightly for a few minutes 2) You're using synergy and the screenblanker never blanks by itself (OK so that's synergy or X's problem but still) Reproducible: Always Steps to Reproduce: 1. See Details 2. 3.
So to turn off the screen from the lockscreen?
(In reply to David Edmundson from comment #1) > So to turn off the screen from the lockscreen? Yes. Many older lockscreens years ago would blank if you hit escape. KDE4 didn't but you could just about make a mostly black screen if you went for the advanced screenlocker and set a black background.
I think we should rather just reduce the screen turn off time to 1 minute when the screen is locked?
I agree both to comment #2 and #3. A screen turn-off time of 1 minute sounds reasonable, as does a keyboard shortcut of Esc to blank the screen. By the way, this would also increase consistency with other desktops (e.g. Mac OS screenlock also blanks the screen on Esc).
what would unblank it?
Any input event (keyboard or mouse), as is already the case AFAIR.
(In reply to David Edmundson from comment #5) > what would unblank it? The unblank rules would be the same as now. We may have to be careful that: 1) If we blank on a key press (e.g. escape) then we don't unblank on the keyrelease. 2) If we blank on a button press then the user is still going to have their hand on the mouse/pad so we need to ignore pointer movements for a fraction of a second; I think the right thing here is just to wait a fraction of a second before doing the blank. (Esc to blank is my preferred keystroke, but I think we did at some point make it clear the password entry, so I'm not sure if it's possible).
Seems reasonable. We should probably do this in kscreenlocker itself though so it applies to all themes, rather than doing it only in the Breeze lock screen theme.
Sounds like a good way of doing it. Coincidentally, I did some tests with blanking from kglobalaccel and it has the problem that since actions get triggered on press, the screens gets restored on released the behaviour is quite meh.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/99
Git commit a1744cf6ce1675184efd3c0057964cb29ecdf686 by Aleix Pol. Committed on 03/11/2022 at 19:04. Pushed by apol into branch 'master'. Pressing Escape turns the outputs off M +1 -0 .kde-ci.yml M +1 -0 CMakeLists.txt M +1 -0 greeter/CMakeLists.txt M +8 -0 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/commit/a1744cf6ce1675184efd3c0057964cb29ecdf686
Thanks!
Pressing ESC when screen is locked does not turn off the display for me in Plasma 6 (KDE Neon Unstable). Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.91.90 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.2.0-34-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 23.3 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630
> Pressing ESC when screen is locked does not turn off the display for me in Plasma 6 (KDE Neon Unstable). Neither works for me using Kubuntu 23.10. Operating System: Kubuntu 23.10 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.0-14-generic (64-bit) Graphics Platform: X11 Graphics Processor: Mesa Intel® Graphics
Works for me on Plasma 5.27 but confirmed broken on 6.0 RC1. A quick log addition shows that in kscreenlocker's greeterapp.cpp, the "else" condition for recognizing the Qt::Key_Escape event [1] is entered as expected, but the KScreen::Dpms::supportedChanged signal did not get emitted. Resolving the bug will mean figuring out why that's not happening. Also, are we creating a new KScreen::Dpms every time the Escape key is hit? That seems just a tiny bit wasteful.
Whoops, meant to add a reference to [1] https://invent.kde.org/plasma/kscreenlocker/-/blob/master/greeter/greeterapp.cpp?ref_type=heads#L626 in the previous comment.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/174
*** Bug 476533 has been marked as a duplicate of this bug. ***
Git commit c37450e186a705e650f294ea7789f21b4133acbb by Jakob Petsovits. Committed on 12/01/2024 at 06:43. Pushed by jpetso into branch 'master'. libdpms: Delay supportedChanged signal until after the constructor KScreen::Dpms was giving promises that it couldn't keep, i.e. blocking in isSupported() until initialization is done. Implementing this safely as specified would involve multithreading or manual event loop processing, both of which seem overkill here. Given the lack of blocking in isSupported(), an owner of the Dpms object could only connect to supportedChanged(). However, this was emitted during the constructor, which makes connections pointless for someone who can only connect after creating the object. To make any of this work, queue the majority of initialization work until after the constructor is called, for both X11 and Wayland. M +2 -2 src/libdpms/dpms.h M +27 -22 src/libdpms/waylanddpmshelper.cpp M +8 -1 src/libdpms/xcbdpmshelper.cpp M +3 -0 src/libdpms/xcbdpmshelper_p.h https://invent.kde.org/plasma/libkscreen/-/commit/c37450e186a705e650f294ea7789f21b4133acbb
Git commit 0660b7d0f47a489ff20e7fcb7bb44746ad730fac by Jakob Petsovits. Committed on 12/01/2024 at 18:27. Pushed by jpetso into branch 'Plasma/6.0'. libdpms: Delay supportedChanged signal until after the constructor KScreen::Dpms was giving promises that it couldn't keep, i.e. blocking in isSupported() until initialization is done. Implementing this safely as specified would involve multithreading or manual event loop processing, both of which seem overkill here. Given the lack of blocking in isSupported(), an owner of the Dpms object could only connect to supportedChanged(). However, this was emitted during the constructor, which makes connections pointless for someone who can only connect after creating the object. To make any of this work, queue the majority of initialization work until after the constructor is called, for both X11 and Wayland. (cherry picked from commit c37450e186a705e650f294ea7789f21b4133acbb) M +2 -2 src/libdpms/dpms.h M +27 -22 src/libdpms/waylanddpmshelper.cpp M +8 -1 src/libdpms/xcbdpmshelper.cpp M +3 -0 src/libdpms/xcbdpmshelper_p.h https://invent.kde.org/plasma/libkscreen/-/commit/0660b7d0f47a489ff20e7fcb7bb44746ad730fac
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/179
Pressing Esc works now as intended, but pressing Esc twice makes the system unresponsive to keyboard and mouse inputs. The only way to recover is REISUB (https://wiki.archlinux.org/title/keyboard_shortcuts#Rebooting). I'm observing this on KDE Neon Unstable.
(In reply to D. Debnath from comment #22) > Pressing Esc works now as intended, but pressing Esc twice makes the system > unresponsive to keyboard and mouse inputs. The only way to recover is REISUB > (https://wiki.archlinux.org/title/keyboard_shortcuts#Rebooting). I'm > observing this on KDE Neon Unstable. Bug 479659 has been opened to track that new problem. Let's keep this one marked as resolved and continue the conversation about inputs in that other bug.
Git commit 504f28d05d9db495c364fc034de5ea9905609a02 by Jakob Petsovits. Committed on 23/01/2024 at 22:50. Pushed by jpetso into branch 'master'. libdpms: Guarantee validity of isSupported() right after construction This reverts commit c37450e186a705e650f294ea7789f21b4133acbb, which fixed turning off the screen on Esc when locked, but broke some DPMS-related functions in PowerDevil, e.g. visibility of display turn-off timeouts in the "Energy Saving" KCM. As a slight change from before though, this does not reintroduce the incorrect API docs statement that isSupported() would block while initializing. Callers can avoid the use of supportedChanged with a good conscience now, unless they track its state over time. M +1 -3 src/libdpms/dpms.h M +19 -24 src/libdpms/waylanddpmshelper.cpp M +0 -7 src/libdpms/xcbdpmshelper.cpp M +0 -3 src/libdpms/xcbdpmshelper_p.h https://invent.kde.org/plasma/libkscreen/-/commit/504f28d05d9db495c364fc034de5ea9905609a02
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libkscreen/-/merge_requests/182
Git commit 67f4c28edb853f4939b26a8a0f85d7ffaf2ab9f7 by Jakob Petsovits. Committed on 23/01/2024 at 23:04. Pushed by jpetso into branch 'Plasma/6.0'. libdpms: Guarantee validity of isSupported() right after construction This reverts commit c37450e186a705e650f294ea7789f21b4133acbb, which fixed turning off the screen on Esc when locked, but broke some DPMS-related functions in PowerDevil, e.g. visibility of display turn-off timeouts in the "Energy Saving" KCM. As a slight change from before though, this does not reintroduce the incorrect API docs statement that isSupported() would block while initializing. Callers can avoid the use of supportedChanged with a good conscience now, unless they track its state over time. (cherry picked from commit 504f28d05d9db495c364fc034de5ea9905609a02) M +1 -3 src/libdpms/dpms.h M +19 -24 src/libdpms/waylanddpmshelper.cpp M +0 -7 src/libdpms/xcbdpmshelper.cpp M +0 -3 src/libdpms/xcbdpmshelper_p.h https://invent.kde.org/plasma/libkscreen/-/commit/67f4c28edb853f4939b26a8a0f85d7ffaf2ab9f7
Git commit 9aa3bd142370d8fa09f1c42b852ad54846f54260 by Jakob Petsovits, on behalf of Prajna Sariputra. Committed on 23/01/2024 at 23:18. Pushed by jpetso into branch 'master'. greeter: Fix pressing Esc to turn off the display The updated KScreen::Dpms documentation guarantees isSupported() to work right after construction, so use it without async instead of the supportedChanged signal which doesn't get emitted anymore during initialization. M +3 -5 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/9aa3bd142370d8fa09f1c42b852ad54846f54260