Gentoo, frameworks-5.23.0, plasma-5.6.95 When I open my laptop, the screen is visible for a moment before the locker hides it. It is nit-picky but it probably shouldn't do that. Reproducible: Always
you are on Intel hardware? I'm experiencing the same problem on my Intel Sandybridge notebook, but not on my Intel Ivybridge desktop system. I spent already in the past quite some time on investigating the issue. I'm quite certain that when we go to suspend the screen is already blanked. Nevertheless it comes up with the old content. I'm at the stage where I think it's a driver issue.
Hi Martin, yes the machine I first noticed this on is a Haswell mobile chip, and since then I have upgraded an older i5 Ironlake (1st gen) laptop and it also shows the problem. On both machines I tried with the "stable" intel graphics release from 2 years ago, as well as a June 2016 snapshot Gentoo has created as a stopgap since Intel doesn't seem to release their software. I cannot reproduce it on my desktop with NVidia proprietary drivers, but my monitors on that machine take so long to leave DPMS they would hide the issue if it were present. I also cannot see the issue on an old laptop with proprietary NVidia (304.x) drivers. I am not sure in that case if the monitor is masking it since it is non-KMS and has a few hiccups when coming out of standby. However it does display an active black screen for a moment before the locker appears, where on my intel gfx hardware, that black screen is my desktop.
*** Bug 366317 has been marked as a duplicate of this bug. ***
I see this issue since the past year, on an [AMD/ATI] Mullins, Radeon R3 Graphics. xf86-video-ati 7.7.0 mesa 12.0.1 linux 4.6.4 Plasma 5.7.2 Qt 5.7.0
I've also been seeing this for a while. Today it was particularly pronounced: the desktop was shown for around ten seconds before the locker finally kicked in. (Usually it's less than a second.) During this time I could move the mouse around, though the windows weren't reactive. The machine in question is Ivy Bridge generation, and is running Linux 4.9.6, the Intel DRM driver (2.99.917.26.20160929), and KDE Plasma 5.8.5.
I still have this issue on 5.9.2 running on a lenovo yoga laptop with intel integrated graphics. does the computer suspend before the screen can lock? If so can this be modified as it is clearly a terrible confidentiality issue.
I forgot to add that it happens when I close the lid and the laptop suspends rather than when it suspends through a command or a time out.
The screen locks before the suspend. From my investigation the issues seems to be in the graphics driver. It just shows the wrong buffer on wake up. If you are on Intel make sure to use the xorg-modesettings driver!
May or may not be related, but it is information. I just witnessed the reverse of this phenomenon on an NVidia graphics based system. My system had enabled the screenlocker, then _just_ before the DPMS kicked in on my monitor, I saw the desktop flash up from behind the locker, then the monitor went to sleep.
This issue should really be upgraded as it is actually quite high in severity from a security standpoint. The delay time is irrelevant to the security issue as the user's screen should NEVER be shown on wake if a password is required on wake. For reference, the delay can be (in my experience) well over 20 seconds which is more than enough time to see critical information that may have been on the screen at suspend time. Bug is reproducible using all methods of sleep, both automatic and user derived. In my case, I am using a very low powered system so the delay is particularly long. This may not be a KDE bug as it has been a bug for at least 6 years in Gnome on Red Hat (https://bugzilla.redhat.com/show_bug.cgi?id=713640). Debian GNU Kernel: 4.9.0-4-686-pae Qt: 5.7.1 KDE Framework: 5.28.0 KDE Plasma: 5.8.6
I've seen this happening too, changing status to Confirmed.
*** This bug has been marked as a duplicate of bug 316734 ***