When waking from resume, the screen locker is delayed by sometimes up to a minute, at which point any videos resume *in the foreground* (defeating the point of screen locker as a privacy aid), and will not let me interact with anything until the password prompt finally appears, at which point I can unlock and interact. Should it not instantly appear and block anything from view before unlock? Cheers
Created attachment 104142 [details] attachment-6492-0.html Which version are you using?
I'm on 5.8.5-0ubuntu1~ubuntu16.10~ppa1 - from https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports?field.series_filter=yakkety (not official ubuntu packages apparently, backports) Cheers
How do you suspend the system? Can you please provide the output of: qdbus org.kde.KWin /KWin supportInformation Please note that the screenlocker does ensure that the screen is locked prior to suspending. We have cases where incorrectly one frame is shown by the GPU driver, but a case like yours has not been described in years and I spent days ensuring that this cannot happen.
I just close the lid and the laptop suspends by ACPI. It resumes and I can see all the data as above. Here's the support info: https://paste.kde.org/plxnvff4o It has also happened before compositing was disabled.
Could you also provide the support information with compositing. That has the interesting part for me. Please also just paste here instead of paste.kde.org as that expires. > I just close the lid and the laptop suspends by ACPI. You are using powerdevil for that? Could you try manually suspend without closing the lid?
OK - I tried manually suspending - this appeared to work just fine. So am I to understand that this isn't a kscreenlocker bug - but a bug with the way suspends are (or are not) handled?
Created attachment 104157 [details] kde info without compositing
> So am I to understand that this isn't a kscreenlocker bug - but a bug with the way suspends are (or are not) handled? Yes, looks like it. I'm reassigning to powerdevil
From what I can tell, closing the lid just simulates a press on the suspend button, so in theory there shouldn't be a difference between manually suspending and closing the lid. What version of systemd and logind are you using? I recall there having been a behavior change in some versions where it would ignore the lid inhibition to let us handle that event and instead would just suspend unconditionally, giving the screen locker no chance to start in time.
Sounds like something reasonable. I've got version 231 of systemd (not sure how to check for logind - same package I presume?
I think that's exactly the version where it broke, sorry. :/ See Bug 366402 for a full explanation (and a workaround), closing this as duplicate then. Thanks for your feedback! *** This bug has been marked as a duplicate of bug 366402 ***
Thanks for confirming et al