in plasma 5.5.5 it worked fine. Reproducible: Always
are you using Qt 5.6?
I am using Qt 5.5.1 under openSUSE Tumbleweed.
I suffer the same issue on Plasma 5.6 using Qt 5.6.0 (Arch's official packages). At first I though it might be a purely configuration issue in System Settings. However even after deleting my `~/.config/kscreenlockerrc` file and tweaking settings I got the same contents there. --> cat ~/.config/kscreenlockerrc [Daemon] LockGrace=15 Timeout=1 [Greeter] Theme=org.kde.breeze.desktop It requires password immediately after locking. I'm sure it's the Lock screen's settings performing the locking, because suspending session settings inside "Power Management" -> "Energe Saving" are set to way more than a minute. Also, I can confirm that this was working smoothly on the same machine with Plasma 5.5.x. @Martin, I would love to help by providing more information about my setup here and everything else that might help debugging this.
We had a weird case under Wayland where it didn't work and we have a patch for that in https://phabricator.kde.org/D957 - it's not merged as we didn't understand the patch. If you could test whether that one helps, that could help us.
Uhm... this is happening under X11 session. Could this still be related?
I can confirm this on Plasma 5.6 and Qt 5.6 on Arch, X11. In fact this is extremely annoying because Chromium refuses to inhibit power management when I'm watching long YouTube videos and suddenly the screen locks and I have to hurriedly enter my password to get back to the video. If you have any tests you'd like me to run, please tell me.
Hmm... this is definitely a regression $ ninja test [1/1] Running tests... Test project /home/bg14ina/.kde/kscr-build Start 1: ksmserver-authenticatorTest 1/4 Test #1: ksmserver-authenticatorTest ...... Passed 2.87 sec Start 2: ksmserver-logindTest 2/4 Test #2: ksmserver-logindTest ............. Passed 0.23 sec Start 3: ksmserver-ksldTest 3/4 Test #3: ksmserver-ksldTest ............... Passed 0.80 sec Start 4: ksmserver-x11LockerTest 4/4 Test #4: ksmserver-x11LockerTest ..........***Failed 5.24 sec 75% tests passed, 1 tests failed out of 4 Total Test time (real) = 9.15 sec The following tests FAILED: 4 - ksmserver-x11LockerTest (Failed) Errors while running CTest FAILED: cd /home/bg14ina/.kde/kscr-build && /usr/bin/ctest --force-new-ctest-process ninja: build stopped: subcommand failed.
Interesting, I just did a debug build and ran both ninja test and the particular test manually, both pass. I'll look into this further in the evening.
(In reply to Kiril Vladimiroff from comment #5) > Uhm... this is happening under X11 session. Could this still be related? aye, as it's the same problem. Grace time not working.
I can confirm this bug in KDE Plasma 5.6.1 with Qt 5.6.0 on OpenSUSE Leap 42.1 where the time delay specified for "Require password after locking" is ignored and a password is required immediately after locking.
*** Bug 361328 has been marked as a duplicate of this bug. ***
*** Bug 360190 has been marked as a duplicate of this bug. ***
possible patch: https://phabricator.kde.org/D1314
Git commit e9984e21b798a0894e49dc74489a8fc7c2c2347d by Martin Gräßlin. Committed on 04/04/2016 at 16:49. Pushed by graesslin into branch 'master'. Workaround problems with Qt::QueuedConnection Summary: For unknown reasons our signals with Qt::QueuedConnection are not delivered with Qt 5.6 if the context object is this (KSldApp instance). If we use a different context object (e.g. the sender) it works. The lack of signals not working triggered quite a few bugs, like * grace time not working * global shortcuts not working Related: bug 361007 Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1314 M +0 -3 autotests/ksldtest.cpp M +6 -2 ksldapp.cpp http://commits.kde.org/kscreenlocker/e9984e21b798a0894e49dc74489a8fc7c2c2347d
Git commit f0d2746615eb823770d14af1ca857918e3e7c399 by Martin Gräßlin. Committed on 05/04/2016 at 08:09. Pushed by graesslin into branch 'Plasma/5.6'. Workaround problems with Qt::QueuedConnection Summary: For unknown reasons our signals with Qt::QueuedConnection are not delivered with Qt 5.5.1 or later if the context object is this (KSldApp instance). If we use a different context object (e.g. the sender) it works. The lack of signals not working triggered quite a few bugs, like * grace time not working * global shortcuts not working Related: bug 361007 FIXED-IN: 5.6.2 Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1314 M +6 -2 ksldapp.cpp http://commits.kde.org/kscreenlocker/f0d2746615eb823770d14af1ca857918e3e7c399