SUMMARY *** Lock-screen, after some indefinite amount of time, will fail to actually display when the machine is taken out of sleep. And, yes, this is a grave matter. This is a UX nightmare, with all due respect because I love KDE. Ostensibly, the lock-screen works as normal at the very start, with laptop lock buttons working expectedly, ie: in accordance with the function of locking. Now, after keeping the computer on lock while being indiscriminate with the amount of time locked, trying to open the machine (laptop in my case) again will have you greeted with only a cursor and both screens activated. However, both screens will be black and your cursor will be trapped on one screen. This happens on a laptop and external monitor setup. Disconnecting the external monitor might actually show me the lock-screen and allow me to login in. I should not have to do this. This kind of issue happens after some unknown time elapsed. It can be a matter of screen-locking from somewhere 30 seconds all up to 6 hours. For instance I tried 5 minutes and I could replicate this issue. *** STEPS TO REPRODUCE 1. Have a laptop with an external monitor. (I do not know about other setups; this is mine) 2. Lock the screen (sleep mode). Wait 5 minutes. 3. Take the laptop out of sleep mode. You should see the issue. OBSERVED RESULT Black screen with cursor shown. No lock-screen elements or way to actually put in the password needed to get back to work/play/whatever. EXPECTED RESULT Functioning lock-screen. SOFTWARE/OS VERSIONS Windows: N/A macOS: N/A Linux/KDE Plasma: Arch Linux, Linux-zen 6.0.12, Plasma X11 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION Intel Core i7, NVIDIA GeForce RTX 2060, MSI GE75 Raider 10SE
Created attachment 154772 [details] Picture shows the problem.
To note: this is seemingly at random. Perhaps not even based off of time but some kind of stability. I don't know. I have tried to unlock my computer from sleep (after hours of my own sleep)... and it worked perfectly. Will return with more comments if need be.
Possibly a GPU issue; see similar bug 457284. Marking as VHI critical because this can cause data loss due to the inability to unlock the screen unless you're an expert who knows how to unlock the screen using a virtual terminal.
If you disable lock after suspend do you still have issues waking up from sleep? Another test: Do you reliably get issues if you lock the screen (without suspend) control+alt+f4 (to switch to another VT) control+alt+f1 (to switch back) That should trigger an nvidia context loss which is what you'll get sometimes with sleep.
(In reply to Nate Graham from comment #3) > Possibly a GPU issue; see similar bug 457284. > > Marking as VHI critical because this can cause data loss due to the > inability to unlock the screen unless you're an expert who knows how to > unlock the screen using a virtual terminal. Well, to provide info. I don't know what else to say but that the bug just stopped happening. It just simply demanifested. If anything happens, I'll tell you guys.
(In reply to Nate Graham from comment #3) > Possibly a GPU issue; see similar bug 457284. > > Marking as VHI critical because this can cause data loss due to the > inability to unlock the screen unless you're an expert who knows how to > unlock the screen using a virtual terminal. Nate. The issue reoccurred. To elaborate: The screen will flicker black and it will display pure black on both monitors.
(In reply to David Edmundson from comment #4) > If you disable lock after suspend do you still have issues waking up from > sleep? > > Another test: > > Do you reliably get issues if you lock the screen (without suspend) > control+alt+f4 (to switch to another VT) > control+alt+f1 (to switch back) > > That should trigger an nvidia context loss which is what you'll get > sometimes with sleep. I did the lock without suspend test you prompted me to here. I locked the screen and switched ttys. It flickers a bit but it will invariably return to the correct lock-screen prompt and I am able to unlock from there.
Thanks for the info.
TO ADD ON: Waking up of sleep+suspension has the bug detailed in my OP, but I can get a lock-screen by unplugging my HDMI and using my built in to log in... Unfortunately this is not really a solution, and it makes my external monitor unusable, given that when plugging in the external monitor again, all screens will shut off and be pitch black. This is beginning to make using KDE unmanageable for my work. If I'm in the middle of programming, I cannot afford to have a lock-screen glitch make me lose all of my progress.
This issue has not occurred since I have updated to 5.26.5. Lockscreen looks good on two tests: one long term, one short term. If after a day's worth of sporadic testing with varying times I no longer experience the issue, I will mark it as fixed in 5.26.5.
Aha, now I know what this bug is: Bug 457284. Other people in there are reporting that it's also fixed for them with 5.26.5. *** This bug has been marked as a duplicate of bug 457284 ***
(In reply to Nate Graham from comment #11) > Aha, now I know what this bug is: Bug 457284. Other people in there are > reporting that it's also fixed for them with 5.26.5. > > *** This bug has been marked as a duplicate of bug 457284 *** Yup. It's fixed. Good work Nate and everyone else at KDE.
The issue occurred again at 9:27 PM. Same description. Put the computer to sleep. Reopen it. Pitch black and only a cursor is shown.
(In reply to Maluchi Ugokwe Jr. from comment #13) > The issue occurred again at 9:27 PM. > > Same description. Put the computer to sleep. Reopen it. Pitch black and only > a cursor is shown. To continue, maybe this was a once in a blue moon kind of rarity for the bug I described to reoccur after I thought it was patched. I don't know if the screenlocker crashed or if the bug was actually not completely fixed.
Darn. `coredumpctl --reverse` will tell you if there are any kscreenlocker_greet crashes. Do you see any?
I had a similar problem with my computer. If I use the lock screen, the computer lags. When unlocked it becomes a black screen and only a cursor is visible. If I just use power management to turn off the screen automatically, there is no problem. My computer only has a single screen and no NVIDIA graphics card installed. --- Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.8 Kernel Version: 5.15.0-57-generic (64-bit) Graphics Platform: X11 Processors: 6 × Intel® Core™ i5-8500 CPU @ 3.00GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 630
(In reply to Nate Graham from comment #15) > Darn. `coredumpctl --reverse` will tell you if there are any > kscreenlocker_greet crashes. Do you see any? No. Only a signal abort on /usr/bin/kwin_x11 and then a subsequent signal segmentation fault on /usr/bin/kwin_x11 So something seriously wrong is happening with kwin for an ABRT to happen, which, if I had to guess, is what's causing this bug.
Has not occurred on 5.27.0. Closing for now.
This is still a bug. Issue is probably with Kwin as well as the screen-locker crashing.
I ran into a similar issue today that eventually degenerated into a total breakdown of the system. I was able to get a stack trace but it was lost when I had to reboot. It all started with a wakeup from sleep with an external screen. Restarting kwin_x11 seemed to have solved the issue, but one day later it started again. The main symptom was kwin_x11 exiting with code 1 (hence no DrKonqi like in the original report). I recall the stack trace being in the default X11 error handler and seeing error messages about the X11 connection being lost. X11 was still running and other applications working properly. I also recall seeing effect classes and GL functions in the last levels of the trace (I know this is very unspecific but that's what I have). At first the issue seemed to be related to a window being activated in fullscreen (both my own Qt app and Zoom). Eventually even notifications coming on top of a fullscreen window appeared to trigger a crash. It even crashed on alt-tabbing. Towards the end (after many kwin restarts) the system also prompted me to increase the inotify limit, but this may be unrelated. I tried upgrading KWin and other packages on the unstable system but it didn't seem to help. I'm now running 5.27.2. System info (after upgrade): ======================= Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 5.19.0-32-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-10310U CPU @ 1.70GHz Memory: 15.3 Gio of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: Dell Inc. Product Name: Latitude 7410
Created attachment 156960 [details] Stack trace of crashing kwin_x11 So it happened again and I was able to gdb in and grab a stack trace of crashing kwin_x11. It looks completely different from the symptoms I described yesterday, not sure why.
(In reply to Louis Moureaux from comment #21) > Created attachment 156960 [details] > Stack trace of crashing kwin_x11 > > So it happened again and I was able to gdb in and grab a stack trace of > crashing kwin_x11. It looks completely different from the symptoms I > described yesterday, not sure why. The issue that I reported seems to no longer be happening to me. Here are my specifications: Operating System: Arch Linux KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.0.12-zen1-1-zen (64-bit) Graphics Platform: X11 I am using NVIDIA GeForce RTX 2060