Bug 316734 - After waking the system, the desktop gets displayed for a moment before the lock screen appears
Summary: After waking the system, the desktop gets displayed for a moment before the l...
Status: CONFIRMED
Alias: None
Product: kscreenlocker
Classification: Unclassified
Component: greeter (show other bugs)
Version: unspecified
Platform: Archlinux Packages Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL: http://forum.kde.org/viewtopic.php?f=...
Keywords:
: 364915 366317 392303 405993 408493 414414 415362 421320 433893 436751 439814 448297 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-14 19:01 UTC by firewalker
Modified: 2022-06-26 21:29 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description firewalker 2013-03-14 19:01:00 UTC
After waking the system from suspend to RAM (sleep function in KDE menu) the session is not immediately locked. It displays the user session for couple of seconds. See the following video.

http://www.youtube.com/watch?v=Jble0nh0fXA

Reproducible: Sometimes

Steps to Reproduce:
1. Suspend the system to RAM using the sleep option.
2. Wake the system.
Actual Results:  
The session is not immediately locked. It displays the user session for couple of seconds.

Expected Results:  
The session should be locked and not to display user information.

http://forum.kde.org/viewtopic.php?f=225&t=110378
http://www.youtube.com/watch?v=Jble0nh0fXA
Comment 1 Josef Kufner 2015-09-14 15:00:56 UTC
This bug is also with KDE 5.4. The ksmserver has the inhibit lock in systemd, but it uses it in a worng way to hold the suspend procedure before lock screen is fully started. Or it does not wait until it is started.

The few seconds is usually about one or half on my system, depending on system load and cache state.

As a workaround I added 3 second sleep into sleep sequence (simple service file), but still there is a race condition which should be resolved.
Comment 2 Kai Uwe Broulik 2016-03-08 10:27:11 UTC
Is that still an issue in Plasma 5.6?
Comment 3 Josef Kufner 2016-03-08 13:21:52 UTC
Since this is matter of security/privacy, the answer should be in form of commit id ;)

I tested it right now and screen went black instead of showing the desktop, but I'm not sure whether it is really fixed because my laptop is not in heavy load. (I have something between 5.5 and 5.6)
Comment 4 Martin Flöser 2016-03-08 15:05:25 UTC
As far as I experience the problem, it's unfortunately not in our scope to fix it. I even see the problem on my Wayland system which actually ensures that no windows are rendered when the screen is locked. The DRM subsystem seems to present an old buffer on resume.
Comment 5 Josef Kufner 2016-03-08 15:07:43 UTC
The buffer must be cleared before suspend. Accordin to what I met in systemd configuration, It should be possible to "inhibit" suspend proces until the buffer is cleared.
Comment 6 Martin Flöser 2016-03-08 15:52:02 UTC
(In reply to Josef Kufner from comment #5)
> The buffer must be cleared before suspend. Accordin to what I met in systemd
> configuration, It should be possible to "inhibit" suspend proces until the
> buffer is cleared.

well that's what we do from kscreenlocker. We adjusted the code to keep the inhibition around till the first frame is definitely rendered. Nevertheless we get an old buffer shown on resume. It works fine on my IvyBridge based system, it doesn't on my SandyBridge based system.

Sorry, but as far as I investigated on my system our code does the right thing.
Comment 7 Josef Kufner 2016-03-08 16:11:43 UTC
Can't it be because of double/tripple buffering? If only the first frame is really rendered, the other half of the buffer will still contain previous screen and after resume the buffers may not be swapped correctly, and if it takes a while to redraw... What if the screen is cleared twice with a sync both in between and after? (Just a wild guess.)
Comment 8 Martin Flöser 2016-03-08 17:01:32 UTC
So I just tried again on my Wayland system:
* screen goes black
* system suspends
* press power
* system wakes up
* shows old content
* shows lock screen

If it would use the last buffer before suspend, it were black and not old screen content.
Comment 9 Andrew Crouthamel 2018-09-26 22:12:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 10 firewalker 2018-09-27 06:30:43 UTC
What kind of info do you need?
Comment 11 Andrew Crouthamel 2018-10-28 03:25:13 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 12 firewalker 2018-10-28 06:58:23 UTC
What kind of information do you need?
Comment 13 Nate Graham 2020-01-31 21:51:15 UTC
I still see this occasionally.
Comment 14 OlafLostViking 2020-02-17 19:38:58 UTC
Still valid.
Comment 15 David Edmundson 2021-03-03 08:26:53 UTC
*** Bug 433893 has been marked as a duplicate of this bug. ***
Comment 16 Andrey 2021-03-14 17:57:48 UTC
I see this quite regularly on the latest Plasma on Arch Linux and it looks like quite a serious security / privacy issue. Happy to help debugging if anyone offers a direction.
Comment 17 David Edmundson 2021-03-14 18:47:44 UTC
>What kind of information do you need?

Anything that disproves the comment in #6
Comment 18 Andrey 2021-03-14 19:33:34 UTC
(In reply to David Edmundson from comment #17)
> >What kind of information do you need?
> 
> Anything that disproves the comment in #6

Not the person you were asking, but I also experience the issue. 

I'm not sure which statement from the comment #6 you want disproved, but my system has Coffee Lake or Cannon Lake architecture. I have another laptop with some Intel Gen 8 platform that is also affected.
Comment 19 Bug Janitor Service 2021-03-29 04:33:32 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 20 David Edmundson 2021-04-11 14:17:41 UTC
I have a theory to rule out:

If someone can reproduce this reliably, could they run "kcmshell5 qtquicksettings" and set their backend to software and see if the screen locker issue perists or goes away
Comment 21 Bug Janitor Service 2021-04-26 04:33:39 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 22 Andrey 2021-04-28 13:38:24 UTC
Doesn't reproduce reliable over here unfortunately, only happens every once in a while.
Comment 23 Alois Wohlschlager 2021-05-10 16:04:03 UTC
*** Bug 436751 has been marked as a duplicate of this bug. ***
Comment 24 Alois Wohlschlager 2021-05-10 16:05:37 UTC
Could the issue described in comment 6 be worked around by blocking the suspend util two (or maybe even three) frames of the lockscreen have been rendered?
Comment 25 Isaac Cohen 2021-05-11 17:13:30 UTC
(In reply to David Edmundson from comment #20)
> I have a theory to rule out:
> 
> If someone can reproduce this reliably, could they run "kcmshell5
> qtquicksettings" and set their backend to software and see if the screen
> locker issue perists or goes away

I could reproduce reliably. I tried what you said and now it works every time. Thanks!
Comment 26 Isaac Cohen 2021-05-11 17:17:21 UTC
Also, I should point out that for me this issue only began when I upgraded to Plasma 5.21. When I used 5.19 it never happened and after I upgraded it happened every time. When filing my big report I actually saw this one but noticed it was from several years ago and so figured it must be a different issue (since mine just started with 5.21). So I filed a separate bug report but it was marked a duplicate of this one. I guess it is the same issue.
Comment 27 Alois Wohlschlager 2021-05-12 08:21:32 UTC
For me it is the opposite behavior. With GPU rendering, I cannot reproduce the bug reliably. Sometimes I see the session content before the lockscreen appears, sometimes I see a black screen with mouse cursor. In software rendering mode, the session is always visible briefly.
Comment 28 Bug Janitor Service 2021-05-27 04:33:45 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 29 David Edmundson 2021-05-27 09:42:20 UTC
>Could the issue described in comment 6 be worked around by blocking the suspend util two (or maybe even three) frames of the lockscreen have been rendered?

That's exactly what it does.

Based on the new software rendering test, what I suspect happens is kscreenlocker is fullscreen and kwin is showing the kscreenlocker window.


We have seen in the past OpenGL clients when creating a new buffer have leaked contents representing an old backbuffer. We could be in that situation if we're processing screen removal and additons which kscreenlocker will treat as a new window.

We typically guard that with sync requests, but because the screenlocker is an override-redirect, that could potentially skipped.

We would need some way to prove that - and if so the fix, somewhat counter intuitively, would be to slow down the screenlocker_greet mapping after creation.
Comment 30 Nate Graham 2021-06-21 21:20:28 UTC
*** Bug 408493 has been marked as a duplicate of this bug. ***
Comment 31 Nate Graham 2021-06-21 21:20:32 UTC
*** Bug 414414 has been marked as a duplicate of this bug. ***
Comment 32 Nate Graham 2021-06-21 21:20:36 UTC
*** Bug 415362 has been marked as a duplicate of this bug. ***
Comment 33 Nate Graham 2021-06-21 21:22:29 UTC
*** Bug 364915 has been marked as a duplicate of this bug. ***
Comment 34 Nate Graham 2021-06-21 21:22:35 UTC
*** Bug 366317 has been marked as a duplicate of this bug. ***
Comment 35 Nate Graham 2021-06-21 21:52:28 UTC
*** Bug 392303 has been marked as a duplicate of this bug. ***
Comment 36 Nate Graham 2021-06-21 22:44:22 UTC
*** Bug 421320 has been marked as a duplicate of this bug. ***
Comment 37 Nate Graham 2021-06-21 22:54:58 UTC
*** Bug 405993 has been marked as a duplicate of this bug. ***
Comment 38 Nate Graham 2021-08-03 17:00:05 UTC
*** Bug 439814 has been marked as a duplicate of this bug. ***
Comment 39 Nate Graham 2021-08-03 17:00:42 UTC
Bumping up to VHI due to number of duplicates.
Comment 40 christian.lange 2021-08-04 07:56:22 UTC
I can not believe that this security issue is still not fixed after so many years. The only workaround is to minimize all windows before you suspend your workstation.
Comment 41 firewalker 2021-08-04 08:35:57 UTC
Even if you minimize everything, some times after waking the system, if the mouse is moved, the screen locker will not show up at all.
Comment 42 Martin Flöser 2021-08-05 08:31:51 UTC
Can those affected by the problem please check dmesg after a suspend cycle for messages related to drm?

Personally I haven't experienced this problem for years (!) any more and given the past I fear that this is a driver issue. Which can make it difficult to investigate. We might need much more information from everyone experiencing this issue. It is possible that this is a driver/distro specific problem.

Thus I would like anybody experiencing the problem as first step try whether the issue also persist on a Wayland session. This is extremely important to know whether the problem is only X11 specific or also on Wayland and thus in general.

Then further I would like every affected user to report:
 * Distribution and version
 * Mesa version
 * Hardware (which CPU and GPU)

This should hopefully give us some more information to understand who is affected and why.
Comment 43 Oliver Stoeneberg 2021-08-05 08:38:35 UTC
It happens on the PinePhone running Manjaro Plasma Mobile with all the latest updates installed.
Comment 44 firewalker 2021-08-05 12:28:14 UTC
Over the years I have seen it happening with nvidia open/closed drivers, ATI open/closed drivers, intel gpus and now amdgpu.
Comment 45 KDamian 2021-08-05 18:42:46 UTC
(In reply to Martin Flöser from comment #42)
> Can those affected by the problem please check dmesg after a suspend cycle
> for messages related to drm?

I checked the dmesg output, I could not find anything related to drm but maybe I am doing something wrong:

https://pastebin.com/akidDFGn


> 
> Personally I haven't experienced this problem for years (!) any more and
> given the past I fear that this is a driver issue. Which can make it
> difficult to investigate. We might need much more information from everyone
> experiencing this issue. It is possible that this is a driver/distro
> specific problem.
> 
> Thus I would like anybody experiencing the problem as first step try whether
> the issue also persist on a Wayland session. This is extremely important to
> know whether the problem is only X11 specific or also on Wayland and thus in
> general.

I could not reproduce on Wayland, X11 I can reproduce consistently.

> 
> Then further I would like every affected user to report:
>  * Distribution and version
>  * Mesa version
>  * Hardware (which CPU and GPU)

Operating System: KDE neon 5.22
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.3
Kernel Version: 5.8.0-63-generic (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-2520M CPU @ 2.50GHz
Graphics Processor: Mesa DRI Intel® HD Graphics 3000
Mesa version: 20.2.6

> 
> This should hopefully give us some more information to understand who is
> affected and why.
Comment 46 Martin Flöser 2021-08-05 18:43:28 UTC
Based on comment #43 I read through the relevant code pieces for Wayland. On Wayland we ensure that when the screen is locked only the lock screen window or input method window should be visible (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/composite.cpp#L608 ). As stated in comment #43 this seems to not work correctly.

By investigating I found two smallish issues which might cause it:
1. There seems to be no full repaint triggered when the screenlocker reports to get locked. In the handler for the aboutToLock signal (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/wayland_server.cpp#L604 ) a full repaint needs to be triggered. This would ensure that KWin stops rendering all windows before the lock screen gets shown. Thus the screen should turn black. (Please note that the code in Kscreenlocker needs to be adjusted as the emit happens before the lock state is changed to AcquiringLock. Maybe a dedicated signal is needed, see https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L380).

2. KWin reports the screen as fully locked once the window for the lock screen is registered (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/wayland_server.cpp#L245 ). At that time it is not yet rendered, not yet even damaged. It is only created. The screenlocker immediately removes the inhibition and the system suspends (see https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L720 and https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L301 ). This needs to be changed to wait for
a) surface fully damaged
b) composition pass finished
c) screen presented (e.g. drm frame callback)

In combination these two issues can create a race condition where the screen stays in the content of the unlocked state. Still it is likely for many systems to not hit the issue. E.g. anything triggering a repaint between aboutToLock and Wayland window created will ensure the screen to go black. This can e.g. happen when clicking a button to suspend (the button release of the mouse will do) or when closing a notebook lid by triggering the common fake touchpad moves in these cases. This especially explains the pinephone case where the system is probably not put to lock through a pointer/touch event.

The second issue explains why the problem came back. The code was written against the wl_shell interface and got migrated over the years to xdg_shell which is a more complex interface and needs more time to setup thus the too early removed inhibition is more likely to cause issues.

Of course this is only for Wayland. For X11 we need other solutions which might be possible to reuse ideas from Wayland.
Comment 47 Nate Graham 2021-11-25 16:23:07 UTC
Cannot reproduce in the Plasma Wayland session with current git master, FWIW.
Comment 48 Martin Flöser 2021-11-30 18:37:01 UTC
(In reply to Nate Graham from comment #47)
> Cannot reproduce in the Plasma Wayland session with current git master, FWIW.

Just experienced the issue on wakeup with relatively recent git master (20211114).
Comment 49 Patrick Silva 2022-01-12 12:37:47 UTC
*** Bug 448297 has been marked as a duplicate of this bug. ***
Comment 50 Shmerl 2022-01-12 16:44:06 UTC
For this got worse in 5.23.5. Happens both in Wayland and X11 session.
Comment 51 indecisiveautomator 2022-01-19 20:53:17 UTC
Unable to reproduce on Arch Linux with Plasma 5.23.90 under Wayland with my desktop PC and laptop.
Comment 52 Bug Janitor Service 2022-01-20 22:27:21 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1919
Comment 53 David Edmundson 2022-01-20 22:32:09 UTC
I also can't reproduce, but we don't need to. What matters is making sure the code is technically correct - and right now it's not.

Using Martin's comments as a baseline:
I don't think we need to worry about part 1, that would also be racey.

I patched 2a above. Then we can add in some new singleshot connect for part 2b and 2c.
Comment 54 Shmerl 2022-01-20 22:45:22 UTC
About reproducing, I get an impression it happens more on desktops and not with laptops.

My motherboard for the reference: Asrock X570 Taichi.
Comment 55 David Edmundson 2022-01-21 13:53:22 UTC
Git commit f2d3c5289ff2508cbfa5b92a18d53888f0dc93a0 by David Edmundson.
Committed on 21/01/2022 at 13:36.
Pushed by davidedmundson into branch 'master'.

Only consider the screen lock shown after the screen window is mapped

This signal is sent back to the ksldapp after the greeter has registered
a window with the compositor. Only once ksldapp gets this signal does it
release the lock delaying suspend.

With xdgshell/layershell we have a roundtrip of configuring before the
window is even exposed, so we move to a different signal. This also
helps encapsulate lockscreen code.

Ideally we want to add code tracking frame rendering per screen tracked
too, but that would be based off this change.

M  +6    -4    src/wayland_server.cpp

https://invent.kde.org/plasma/kwin/commit/f2d3c5289ff2508cbfa5b92a18d53888f0dc93a0
Comment 56 Nate Graham 2022-01-21 19:10:49 UTC
Can anyone who was able to reproduce the issue see if that resolves it for them?

You'll have to either compile the code form source, or use git master KDE packages from KDE Neon Unstable, OpenSUSE Krypton, or something similar.
Comment 57 Shmerl 2022-01-23 06:05:19 UTC
(In reply to Nate Graham from comment #56)
> Can anyone who was able to reproduce the issue see if that resolves it for
> them?
> 
> You'll have to either compile the code form source, or use git master KDE
> packages from KDE Neon Unstable, OpenSUSE Krypton, or something similar.

Tested it with Plasma 5.23.5 in Debian testing with patching kwin wayland packages. The issue is indeed fixed (in the Wayland session). On resume it now shows a black screen before lock screen appears, instead of a leaked screen from the past session.
Comment 58 Oded Arbel 2022-01-23 13:09:04 UTC
Tested with X11 on current Neon unstable and it looks like the issue is no longer apparent.
Comment 59 Nate Graham 2022-01-23 14:54:27 UTC
Fantastic!
Comment 60 Shmerl 2022-01-23 16:58:45 UTC
(In reply to Oded Arbel from comment #58)
> Tested with X11 on current Neon unstable and it looks like the issue is no
> longer apparent.

I haven't tested it with X11, but is the code shared for it too? It's in wayland_server.cpp, so I assumed it only fixes the Wayland use case.
Comment 61 Martin Flöser 2022-01-23 19:01:10 UTC
(In reply to Shmerl from comment #60)
> I haven't tested it with X11, but is the code shared for it too? It's in
> wayland_server.cpp, so I assumed it only fixes the Wayland use case.

The patch is Wayland only! This change does not have any influence on X11. I am not sure whether we have any chance to fix this for good on X11.

Concerning Wayland I am also not yet convinced that we should consider it as fixed. The patch only addresses point 2a which means we can still enter racy conditions especially on multiple output setups. We still do not wait for the page flip of every output. Though it is very unlikely to hit and on resume the time an old buffer would be shown is shorter.
Comment 62 postix 2022-01-29 20:12:55 UTC
(In reply to Martin Flöser from comment #61)
> The patch is Wayland only! This change does not have any influence on X11. I
> am not sure whether we have any chance to fix this for good on X11.
> 
> Concerning Wayland I am also not yet convinced that we should consider it as
> fixed. The patch only addresses point 2a which means we can still enter racy
> conditions especially on multiple output setups.

Martin, would you like to reopen then or do you create another bug report for the remaining issues?
Comment 63 Patrick Silva 2022-05-30 13:47:52 UTC
This bug persists even on Wayland.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.25.80
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Graphics Platform: Wayland
Comment 64 Joshua T 2022-06-01 13:43:36 UTC
I am still getting this bug on Plasma 5.24.90 (5.25 beta). It is very annoying and happens literally everytime I close and open my laptop. 

OS: Ubuntu Studio 22.10
KDE Plasma Version: 5.24.90
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.0-24-lowlatency (64-bit)
Graphics Platform: Wayland
Comment 65 Nate Graham 2022-06-01 13:54:35 UTC
I can reproduce that. :( For me it was gone for a while, but re-appeared sometime in the last two weeks or so. Perhaps it could be connected to all the recent screen locking work. Or maybe it's a KWin regression.