Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Go to Sleep 2.Touch a key on keyboard, wait 1/8th of a second 3.See the desktop for a second (or so) before login screen appears
Keywords: (none) => 8beta2, 8rc1
I thanks reporting this. Can you provide me the Desktop Environment in use with this session?
CC: (none) => ouaurelien
On the oldest computer a An Acer Travelmate Sleep to Locked screen works, and also it appears to bring up the lockscreen BEFORE sleeping Operating System: Mageia 8 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-desktop-1.mga8 OS Type: 64-bit Processors: 4 × Intel® Core™ i7 CPU M 640 @ 2.80GHz Memory: 7.5 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics On the newest ASUS latop it sleeps in 1/10th of a second, less, like a light switch, returns in les than a second, shows desktop for a second, lockscreen appears Operating System: Mageia 8 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-desktop-1.mga8 OS Type: 64-bit Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.1 GiB of RAM Graphics Processor: AMD RENOIR On the old tower, quick off, quick back, desktop for a second, then lockscreen Operating System: Mageia 8 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-desktop-1.mga8 OS Type: 64-bit Processors: 8 × AMD Ryzen 5 1500X Quad-Core Processor Memory: 7.8 GiB of RAM Graphics Processor: AMD Radeon ™ RX 460 Graphics
CC: (none) => fri
I saw this at suspend/resume on RC Live xfce (32 or 64 bit i dont remember) on a fast USB stick, with persistence, on Thinkpad T400. (Have not tried recently)
Hi, thanks reporting this. 3 different systems affected, not specific hardware "en cause"... Common denominator: Plasma/KDE and kscreenlocker. On my system, nvidia-based with nvidia-current drivers, with Plasma: I can't reproduce. All I see is a tty switch to boot console, some lines written, quick behaviour. Not an unusable desktop. BUT: see a desktop before a screenlocker is a "privacy" bug, notably if you manipulate sensitive datas. This short time before login screen, how long does it occur? 1, 2 or several seconds?
It was about a second here, xfce live. Enough time to get an idea what the user is working with, and read a couple sentences. I dont know how these things work, but shouldnt the screenlocker start and come up fully before system go into suspend, so it is up already when waking?
I read somewhere that normally, graphic card memorizes the last screen when it goes to sleep and should restore it when resume. Nvidia-cards by their nonfree drivers can't. That's why I can't reproduce on my system. I should try this behaviour by removing it and use the CPU graphic part on my Intel processor.... (In reply to Morgan Leijström from comment #5) > I dont know how these things work, but shouldnt the screenlocker start and > come up fully before system go into suspend, so it is up already when waking? Meanwhile, well citizen screenlocker should display itself before system is going to sleep. That is a other question... This can land in a wiki page... I really don't know if it is an errata one as it not our bugs rather an upstream one... But, we should be able to reproduce it with an Intel GPU or an AMD one.
> Not an unusable desktop. Yes, it is not a useable desktop in any way.
What about the status of this? Recent kernel and systemd updates...
Status: NEW => NEEDINFO
Reporter, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
Keywords: 8beta2, 8rc1 => NEEDINFO
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above in Comment 4, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Resolution: (none) => OLDStatus: NEEDINFO => RESOLVED