My monitor doesn’t have buttons (I have an Apple Studio Monitor) so I depend on the OS to sleep the monitor. I either let the monitor time out, or if I’m intentionally walking away I lock the screen to force sleep. That half works just fine.
When I come back to the computer and unlock it, the monitor wakes fast and shows me the background I configured for the lock screen. And then it just sits there. I can move my mouse and see the cursor move, but it takes 30-60 seconds for the login form to appear so I can log in and unlock the computer. I’ve tried moving the mouse, clicking the mouse, pressing enter, pressing control, to see if it’s waiting for a specific input… sometimes my flailing about causes the form to think I attempted a log in and, upon appearing, times out and makes me wait before I can log in.
It’s incredibly frustrating specifically because it’s such a small misbehavior. I’m not sure how I can have screen blanking (both automatically and on command) without the locker, but the frustration involved in the lock screen has me wondering if I can disable it and still get screen blanking. I’ve spent most of my Linux career in GNOME so I might be missing a setting or KDE knowledge that would help here.
Can I change lock screen behavior? Can I blank and sleep monitors without locking? Can I change the app that handles screen locking?
Yes, you can set it to never lock in System Settings, search for “lock” if you don’t quickly see it.
You can set the screen power savings to blank at your desired time in System Settings as well.
If the system is suspending (sleep to ram) some driver on your system may be taking a long time to reload, and not be related to the monitor at all, or KDE
the first one should control the power state and the second one only controls the appearance of the lock screen but does not turn off the monitor.
the behavior sounds like the monitor was never really powered down, and the delay you are noticing could be the time it takes your system to wake from sleep.
there are several sleep states, some of which are slower to wake from than others but that goes deeper than the GUI settings if you want to control that.
there is another utility called gddccontrol control that you can install which gives you more control over the monitor features (if they are exposed).
Previously, Power Management/Energy Saving had “Screen Energy Saving” at 10 minutes, and ‘Suspend Session’ disabled; Screen Locking is set to lock screen automatically at 15 minutes as in the screenshot on skyfishgoo’s post.
I’m glad to know that Screen Energy Saving is separate from Locking.
I had disabled all forms of sleep that I could, because I often leave tasks running overnight that I don’t want interrupted by sleep; I have my power settings on Performance. I turn off lights when I’m not using them and set my thermostat higher than I like to save energy; I let my computer splurge and always disable all forms of sleep. Therefore, the lock screen shouldn’t be hanging on a driver or something from sleep.
To clarify: when I move my mouse after the computer is locked, the screens wake up IMMEDIATELY and show my lockscreen background. The problem is that the login form for me to imput my password takes 60 seconds or so to appear on top of the background. I don’t know what’s causing the delay between the monitors waking up and the password field appearing.
I’ve disabled locking for now and just have the automatic screen blanking, which half-fixes the problem. Is there a way to manually invoke screen blanking? I’m OK with the computer not being locked-locked, but when it’s time to go to bed I don’t really want my monitors blazing away in my room for 15-ish minutes.
I have the exact opposite problem. When I manually lock the screen, which will then turn it off after 30 seconds, it will recover instantly, even after many hours. However, if I let the screen blank due to inactivity, and then allow it to lock itself and the monitors to turn off, it takes 30ish seconds to show me the password screen after its been off for 15 mins or so.
This is in X11.
The issue for me started after I updated the Nvidia driver to 570 from 550. The system is also having a hard time launching, with Kwin crashing regularly on login. When it logs in correctly (1 in 5 attempts), it runs fine, with the exception of the above issue.
The problem for me is exclusively X11. Wayland works fine, but its limitations are to many and I cannot use it. I could revert to 550, but it has its own limitations that outweigh the hassles brought with 570.
I wish Nvidia and/or the Plasma Wayland team would give us proper driver controls in Wayland. While X11s controls are still weak compared to Windows, Wayland has none at all. At very least I need proper access to color.
There is a fix mentioned in the bug report where the greeter is replaced by a shell script - that worked for me with Plasma 6.4.0. Earlier on, even that did not work, so I went back to the 550 driver (for X11).
Now that I’m on Plasma 6.4.1 and Nvidia 570.169 it no longer appears to be happening. But it doesn’t always happen, so I’m waiting a day or so before commenting on the bug report.
It’s rare, but just now I saw something like a 30+ second delay with no prompts before the lock screen brought up the normal prompts. I see this in journal:
Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost.
Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, cleaning up scenegraph and releasing RHI
Jun 29 19:19:10 ... kscreenlocker_greet[16211]: QRhiGles2: Context is lost.
Jun 29 19:19:10 ... kscreenlocker_greet[16211]: Graphics device lost, cleaning up scenegraph and releasing RHI
Rather than restoring my Tumbleweed system back to 550, I decided to stay with 6.4.1 570.169-37.
Given there is still the odd glitch with the lock screen greeter, I’ve resorted to the suggested shell script wrapper for kscreenlocker_greet mentioned in comment #83 of the bug report. Or at least a variation of it:
#!/bin/bash
rc=1
while [ $rc -ne 0 ]
do
QT_QUICK_BACKEND=software /usr/libexec/kscreenlocker_greet.dist "$@" 2>&1 | logger -t greeter
rc=${PIPESTATUS[0]}
if [ $rc -ne 0 ]
then
logger -t greeter "Exited with rc=$rc - sleeping 2"
sleep 2
fi
rc=$?
done
logger -t greeter "Exited with rc=$rc"`
With that in place, unlock still seems a little slow to react, but it has always consistently worked (so far).
I normally use X11, which seems fine now. Wayland also seems better with the 570 driver than the 550. If I did not wish experiment with Wayland, then sticking with the 550 driver would probably be the better option until things get sorted.
