This is a possible variant of https://bugs.kde.org/show_bug.cgi?id=348850 & https://bugs.kde.org/show_bug.cgi?id=344427 or caused by the same component(s) On a laptop, when sending the OS into standby, then resuming again (such as closing the lid, then opening it), the lockscreen doesn't immediately show. It always shows the current desktop, sometimes long enough to manipulate it (today it was enough to open NM applet and trying to connect to WiFi after I thought that KDE decided no need for a lockscreen today!) When it's quick, it shows the current session (which is a security issue). When it's longer you can move the mouse around or even type something (another security issue where it could be used to execute a script that kills lockscreen) Here's the output of qdbus org.kde.KWin /KWin supportInformation: https://paste.kde.org/puaufjov1 I don't have glxinfo, but compositing is enabled in System Settings Reproducible: Always Steps to Reproduce: 1. Send the PC into standby 2. Resume 3. Session appears first, then lockscreen Actual Results: Session appears first (completely usable), then lockscreen loads Expected Results: Lockscreen is the first thing that loads. Session isn't visible
* are you using logind? * how do you send the PC into standby?
Yes, I'm using logind & SDDM I usually send it through the power button. I've set it to Standby when clicked. It resumes when I open the lid
> I've set it to Standby when clicked where did you configure that?
The KDE Power Management (PowerDevil)
I'm currently trying to reproduce, but my power button do not work. Can you please verify with the tool xev whether the button reports key events? Maybe they are handled in the linux kernel without ever reaching our software....
Are you looking for a particular event? I can't post all of the output, because when I clicked the power button, it went into standby and I typed my password Anyway, it's not about the power button. The problem can still be reproduced when clicking the button in the App Launcher IIRC
> The problem can still be reproduced when clicking the button in the App Launcher IIRC Including that you can interact with the system? That the screen "looks" unlocked is normal, but it should be impossible to interact with keyboard/mouse.
The interaction with a mouse/keyboard happened after a particularly heavy IO operation (I think I was doing some work on a VM. I don't remember the exact things I was doing that day). I've only noticed it long enough this once
> The interaction with a mouse/keyboard happened after a particularly heavy IO operation ah that's a particular important piece of information. I guess there is nothing we can do about that. If ksmserver needs to be swapped in it might be that the logind timeout is reached before ksmserver had a chance to handle the suspend request. That's unfortunate but I don't see what we can do about it.
for what is worth to mention: Wayland will make such situations impossible. As the lock screen will move into the compositor we can be sure that the lock screen functionality will not be swapped out and that input events will reach the compositor only after the suspend request.
I did heavy IO that night, but it was done some time before standby (and I went to do other things after) Wouldn't this be an attack angle (the timeout)? The standby process went without problems, and if logind timed out, why did the lockscreen appear on resume?
> I did heavy IO that night, but it was done some time before standby (and I went to do other things after) it might be that ksmserver was swapped out and not needed before, so be swapped in again. > Wouldn't this be an attack angle (the timeout)? yes, but only if the system is already owned. > The standby process went without problems, and if logind timed out, why did the lockscreen appear on resume? the signal was emitted, it was just that ksmserver did not handle the request yet. So after resume it handled it but had no idea that the system already resumed again.
> the signal was emitted, it was just that ksmserver did not handle the request yet. So after resume it handled it but had no idea that the system already resumed again. Makes sense So what becomes of this bug report then?
> So what becomes of this bug report then? not sure yet. I haven't completely made up my mind whether there is a chance that we can do anything about it.
It happened again. No heavy IO, just a day of regular internet browsing and some films in MP4 (VLC) This time, it was for about a second and a half, but I definitely moved the mouse around
> but I definitely moved the mouse around moving mouse around is fine, but did it react to clicks?
I didn't get enough time to click, and I don't know how I can reproduce it In the original report (the first time) it was much longer, and I was able to open NM-applet and disconnect/connect
any news? Did it happen again?
No, not exactly The screen was visible, and the cursor moved around, but I couldn't click anything.
I hit submit when I meant to hit enter. To clarify further, even though the time of visibility was long, the screen wasn't reactive (it was similar to a picture). The items didn't respond to clicking
ok, that matches the known limitations: the screen locks, but the greeter doesn't show. We improved that in 5.5 significantly.