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
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.
Is that still an issue in Plasma 5.6?
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)
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.
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.
(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.
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.)
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.
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!
What kind of info do you need?
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!
What kind of information do you need?
I still see this occasionally.
Still valid.
*** Bug 433893 has been marked as a duplicate of this bug. ***
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.
>What kind of information do you need? Anything that disproves the comment in #6
(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.
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!
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
Doesn't reproduce reliable over here unfortunately, only happens every once in a while.
*** Bug 436751 has been marked as a duplicate of this bug. ***
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?
(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!
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.
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.
>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.
*** Bug 408493 has been marked as a duplicate of this bug. ***
*** Bug 414414 has been marked as a duplicate of this bug. ***
*** Bug 415362 has been marked as a duplicate of this bug. ***
*** Bug 364915 has been marked as a duplicate of this bug. ***
*** Bug 366317 has been marked as a duplicate of this bug. ***
*** Bug 392303 has been marked as a duplicate of this bug. ***
*** Bug 421320 has been marked as a duplicate of this bug. ***
*** Bug 405993 has been marked as a duplicate of this bug. ***
*** Bug 439814 has been marked as a duplicate of this bug. ***
Bumping up to VHI due to number of duplicates.
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.
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.
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.
It happens on the PinePhone running Manjaro Plasma Mobile with all the latest updates installed.
Over the years I have seen it happening with nvidia open/closed drivers, ATI open/closed drivers, intel gpus and now amdgpu.
(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.
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.
Cannot reproduce in the Plasma Wayland session with current git master, FWIW.
(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).
*** Bug 448297 has been marked as a duplicate of this bug. ***
For this got worse in 5.23.5. Happens both in Wayland and X11 session.
Unable to reproduce on Arch Linux with Plasma 5.23.90 under Wayland with my desktop PC and laptop.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1919
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.
About reproducing, I get an impression it happens more on desktops and not with laptops. My motherboard for the reference: Asrock X570 Taichi.
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
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.
(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.
Tested with X11 on current Neon unstable and it looks like the issue is no longer apparent.
Fantastic!
(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.
(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.
(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?
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
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
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.
Raising priority due to number of duplicates and security/privacy implications.
*** Bug 454129 has been marked as a duplicate of this bug. ***
*** Bug 459441 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/101
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2993
Git commit 3af2d93c2ebe20bfe6effeb55daa622f5eb3aa34 by Xaver Hugl. Committed on 23/09/2022 at 12:48. Pushed by zamundaaa into branch 'master'. waylandserver: handle lock state changing properly M +2 -2 src/wayland_server.cpp https://invent.kde.org/plasma/kwin/commit/3af2d93c2ebe20bfe6effeb55daa622f5eb3aa34
Git commit 9343d391809c91d2d0297e57bcb963c42533e135 by Xaver Hugl. Committed on 23/09/2022 at 13:20. Pushed by zamundaaa into branch 'Plasma/5.26'. waylandserver: handle lock state changing properly (cherry picked from commit 3af2d93c2ebe20bfe6effeb55daa622f5eb3aa34) M +2 -2 src/wayland_server.cpp https://invent.kde.org/plasma/kwin/commit/9343d391809c91d2d0297e57bcb963c42533e135
This is still occuring as of plasma 5.27.3 Reopening this rather than creating yet another duplicate. If you want a new bug, I can do that too. This problem has been (re)appearing for 10 years now. Was/is this ever going to be fixed properly, and permanently *on X11*? As requested some time ago: > please check dmesg after a suspend cycle for messages related to drm? Dmesg snip from suspend -> resume cycle: https://bpa.st/O5ATM ^ | grep -i drm: [drm] PCIE GART of 512M enabled (table at 0x0000008000300000). [drm] PSP is resuming... [drm] reserve 0xa00000 from 0x82fd000000 for PSP TMR [drm] DMUB hardware initialized: version=0x02020017 [drm] kiq ring mec 2 pipe 1 q 0 [drm] VCN decode and encode initialized successfully(under DPG Mode). [drm] JPEG decode initialized successfully. > try whether the issue also persist on a Wayland session. No. I do not have wayland or anything related to it installed, nor do I intend to. > I would like every affected user to report: > * Distribution and version > * Mesa version > * Hardware (which CPU and GPU) Gentoo current (2.13) Mesa 23.0.0 CPU: Intel I9-10900KF GPU: AMD Radeon RX 6700 XT Anything else you need?
>Was/is this ever going to be fixed properly, and permanently *on X11*? The discussion above are is not for X11. We have a lot less control there. It's the sort of thing we're doing the wayland port for. In terms of new information, you can add a timer on LogindIntegration::uninhibit and see if that alleviates the symptoms.
The problem is still persistent on my laptop (with HDD), if I click on sleep with so many opened apps, the screen is shown after waking from sleep then the lock is applied. Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.12-1-MANJARO (64-bit) Graphics Platform: X11
As David hinted at, this is fixable on Wayland, but it's a game of whack-a-mole on X11. It's one of those things where if you want a better experience here, use Wayland.
(In reply to Nate Graham from comment #76) > As David hinted at, this is fixable on Wayland, but it's a game of > whack-a-mole on X11. It's one of those things where if you want a better > experience here, use Wayland. Wayland has really too many bugs that prohibit me from using it, X11 is still much more stable and mature.
Nevertheless, I'm afraid that's just how things are. Please make sure you're submitting bug reports on the issues you encounter on Wayland, or there's less of a chance they'll get fixed.
(In reply to Nate Graham from comment #78) > Nevertheless, I'm afraid that's just how things are. > > Please make sure you're submitting bug reports on the issues you encounter > on Wayland, or there's less of a chance they'll get fixed. Can't Plasma power manager simply locks the session before putting it to sleep ?
>Can't Plasma power manager simply locks the session before putting it to sleep ? It literally does.
*** Bug 469063 has been marked as a duplicate of this bug. ***
*** Bug 383527 has been marked as a duplicate of this bug. ***