This seems to be a very close duplicate of https://bugs.kde.org/show_bug.cgi?id=451386, which was marked as resolved, albeit with two differences: 1. I am using X11 and not Wayland. 2. My problem has persisted across many versions of Plasmashell, SDDM, and Kwin, and has never gone away. STEPS TO REPRODUCE 1. Let the computer go into "suspend" state. 2. Attempt to resume. OBSERVED RESULT Screen is entirely black except for the cursor, which I can move freely. Typing password blindly does not appear to have an effect. Switching to TTY3 and trying to restart SDDM results in a cascade of errors and Plasma/KWin is not usable. loginctl unlock-session has no effect. plasmashell --replace emits an error about missing plugins, regardless of what i set DISPLAY to. The only thing that works is rebooting with systemctl. TTY switching works without any problems and nothing seems broken in the console environment. EXPECTED RESULT SDDM appears when waking from sleep, and I can log in. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Endeavour OS KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.11 Kernel Version: 6.1.56-1-lts (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION There is no evidence of a "crash" in dmesg or journalctl output, but I will attach some logs from the last time this problem occurred.
Created attachment 162291 [details] journalctl --user -u plasma-plasmashell
Created attachment 162292 [details] journalctl --user -u plasma-kwin_x11
Created attachment 162293 [details] dmesg
Created attachment 162337 [details] Screen after waking from sleep
Created attachment 162338 [details] DISPLAY=:0 plasmashell --replace
Created attachment 162339 [details] coredumpctl info This is the coredump from plasmashell --replace.
Does the issue go away if you restart plasmashell with `plasmashell --replace` in a terminal window? You shouldn't need to set "DISPLAY=:0"; that seems like it could be a sign of something deeper going wrong underneath Plasma.
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!
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!
(In reply to Nate Graham from comment #7) > Does the issue go away if you restart plasmashell with `plasmashell > --replace` in a terminal window? You shouldn't need to set "DISPLAY=:0"; > that seems like it could be a sign of something deeper going wrong > underneath Plasma. No, I am unable to run plasmashell --replace. I get the Qt error about being unable to load the "xcb" plugin. This happens with or without the DISPLAY env var setting.
It sounds to me like you're missing system components or have a local misconfiguration that has caused DISPLAY to become unset or something. In the absence of evidence that there's a KDE issue here, I'd recommend seeking help in the Arch forum. Let us know what they find. Thanks!
(In reply to Nate Graham from comment #11) > It sounds to me like you're missing system components or have a local > misconfiguration that has caused DISPLAY to become unset or something. In > the absence of evidence that there's a KDE issue here, I'd recommend seeking > help in the Arch forum. Let us know what they find. Thanks! I'm not sure I follow. Under normal circumstances, yes, I can run that command no problem without setting extra environment variables. However in the specific situation I am describing, it fails. That is, the system wakes from sleep showing nothing but a black screen with a cursor. When I switch over to a TTY that is not occupied by a graphical session, that is when the command fails, and only then. If you still think this is not a KDE bug then so be it. But I would certainly be surprised if a system misconfiguration could lead to this particular problem, without causing more systemic issues that I do not have.
(In reply to Nate Graham from comment #11) > It sounds to me like you're missing system components or have a local > misconfiguration that has caused DISPLAY to become unset or something. In > the absence of evidence that there's a KDE issue here, I'd recommend seeking > help in the Arch forum. Let us know what they find. Thanks! It looks like this is a known issue that has no accepted resolution: https://forum.endeavouros.com/t/blank-screen-with-mouse-cursor-after-wake-from-sleep-kde/6870 https://forum.endeavouros.com/t/blank-screen-with-mouse-cursor-after-wake-from-sleep/33948/3 To address some of the comments in the above threads, I am using Nvidia with the proprietary driver, and the Linux LTS kernel. Also, I might have found a lead on diagnosing the problem: it seems to happen more often when a Neovim-Qt window is open at the time the computer goes to sleep. I'm not totally sure of how strong the correlation is, or if it happens with other Qt-based applications.
My panel becomes unresponsive after resume, Usually I would recover with "killall plasmashell && plasmashell", but this time I attempted "plasmashell --replace" and I got: kf.dbusaddons: Couldn't register name 'org.kde.plasmashell' with DBUS - another process owns it already! Needless to say, it wouldn't recover without killing plasmashell first.
For what it's worth, I get this issue with the KDE Plasma 6.0 Beta 1 release (as installed by arch's kde-unstable repo) using Wayland. I'm trying to capture logs to file a report. It does not happen with the stable KDE Plasma release.
Could you please test 1. toggling compositing with Shift+Alt+F12 when the system is in the broken state 2. disabling compositing before putting the system in standby in the first place 3. the same scenario in a different session like openbox 4. the same thing with a new user account (if 3 doesn't work) (In reply to Jean-Francois Roy from comment #15) > For what it's worth, I get this issue with the KDE Plasma 6.0 Beta 1 release > (as installed by arch's kde-unstable repo) using Wayland. I'm trying to > capture logs to file a report. It does not happen with the stable KDE Plasma > release. See bug 477738 for that. (In reply to petrk from comment #14) > My panel becomes unresponsive after resume, Usually I would recover with > "killall plasmashell && plasmashell", but this time I attempted "plasmashell > --replace" and I got: > kf.dbusaddons: Couldn't register name 'org.kde.plasmashell' with DBUS - > another process owns it already! > Needless to say, it wouldn't recover without killing plasmashell first. That sounds unrelated to this bug report, please file a separate one for plasmashell.
> (In reply to Jean-Francois Roy from comment #15) > > For what it's worth, I get this issue with the KDE Plasma 6.0 Beta 1 release > > (as installed by arch's kde-unstable repo) using Wayland. I'm trying to > > capture logs to file a report. It does not happen with the stable KDE Plasma > > release. > See bug 477738 for that. I'll follow up in that bug or in a new bug -- my system is a desktop that never suspends. What seems to trigger it for me is powering down the displays after idle.
I'm doing my best to actually reproduce this again so I can try the above steps. I have not been able to trigger it reliably in recent weeks. I did however confirm that toggling compositing appears to have no effect. It's not even clear to me if the problem lies with KWin or SDDM. I also have not had the time to set up an alternative DE, especially given that reproducing the bug seems difficult now and it will take a long time to I feel confident that it does not happen under another DE. I'd appreciate if this could stay open. I have not lost track of it and I am doing my best to provide any info I can. (In reply to Bug Janitor Service from comment #18) > 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!
It is not clear from the messages whether there is an Nvidia config for turning on the video card after exiting standby mode. I use such a settings file and there are no problems with exiting standby mode. This is usually the file /etc/modprobe.d/nvidia-power-management.conf with content # The destination should not be using tmpfs, so we prefer # /var/tmp instead of /tmp options nvidia NVreg_PreserveVideoMemoryAllocations=1 options nvidia NVreg_TemporaryFilePath=/var/tmp
Created attachment 164796 [details] sudo journalctl -b 0 -u sddm.service
I have made some progress by accidentally reproducing the bug under conditions I didn't expect. I suspect now that SDDM specifically is involved, moreso than KWin or Plasmashell. KWin and/or Plasmashell does seem to suffer some progressive graphics corruption after waking from sleep. That is, if the system goes to sleep several times, eventually there will be graphics glitches that are not solved by toggling compositing or restarting Plasmashell, e.g. solid color blocks, panel buttons not responding, windows flickering when being moved, etc. That is not the problem I am reporting here, but it might be related. Specifically, I reproduced the bug just now under the following circumstances: 1. Wake from sleep and log in to the currently-running session through SDDM; observe lots of graphics glitches, rendering the desktop borderline unusable. Can't even open the KDE applications menu to log out. 2. Log in on TTY 3 as a different user, and use `loginctl terminate-user` to end the graphical session. 3. Switch back to TTY 2 where the graphical session was. At step 3, I was expecting the normal SDDM user selection screen. Instead, I was surprised to find the same black screen with cursor that I had been seeing previously upon wake from sleep. Therefore while there does seem to be some issue with KWin and Plasmashell becoming corrupted after several sleep cycles, the actual error was triggered only when the user was logged out and SDDM was supposed to appear on TTY 2. There is an error in the SDDM log, I have added it as an attachment: https://bugs.kde.org/attachment.cgi?id=164796 I'm not sure if the bug is in SDDM, X.org, Plasmashell, KWin, the Nvidia driver or elsewhere. But I hope that being able to reproduce it under different circumstances, and having a new error message, might act as additional evidence. I am not familiar with the Nvidia config file in modprobe.d, and I do not have that file on my system. I will do some research, try that suggestion, and see if it helps. Thanks again for not closing this ticket.
(In reply to kde-bugzilla from comment #22) > I am not familiar with the Nvidia config file in modprobe.d, and I do not > have that file on my system. I will do some research, try that suggestion, > and see if it helps. You can read it here at the bottom of the page https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks
JFYI, what you see after locking the screen is not SDDM but rather the lock screen. You'd only see SDDM if you logged out or switched users prior to putting the user to sleep. Otherwise you're seeing the lock screen.
I think I am seeing this regularly but on Wayland. If I kill kscreenlocker_greet from an ssh or tty session, I can see and use my graphical session again, without needing to unlock the session first with loginctl.
(In reply to Jean-Francois Roy from comment #25) > I think I am seeing this regularly but on Wayland. If I kill > kscreenlocker_greet from an ssh or tty session, I can see and use my > graphical session again, without needing to unlock the session first with > loginctl. I had a similar problem. It turned out that qt5-qtvirtualkeboard was assembled incorrectly. To check, I deleted qt5-qtvirtualkeboard, and after that the problem went away. There was a patch in the qt5-qtvirtualkeboard package that caused this behavior. I removed the patch and the problem went away. This was maybe a year ago. Since then no problems with Nvidia. On kde5 and kde6.
(In reply to Jean-Francois Roy from comment #25) > I think I am seeing this regularly but on Wayland. If I kill > kscreenlocker_greet from an ssh or tty session, I can see and use my > graphical session again, without needing to unlock the session first with > loginctl. I forgot to add that I see nothing interesting in the journal, but I don't have any extra debug logging env or flags set.
(In reply to Victor Ryzhykh from comment #26) > (In reply to Jean-Francois Roy from comment #25) > > I think I am seeing this regularly but on Wayland. If I kill > > kscreenlocker_greet from an ssh or tty session, I can see and use my > > graphical session again, without needing to unlock the session first with > > loginctl. > > I had a similar problem. > It turned out that qt5-qtvirtualkeboard was assembled incorrectly. > To check, I deleted qt5-qtvirtualkeboard, and after that the problem went > away. > There was a patch in the qt5-qtvirtualkeboard package that caused this > behavior. > I removed the patch and the problem went away. This was maybe a year ago. > Since then no problems with Nvidia. > On kde5 and kde6. I'll try w/o qt6-virtualkeyboard (I'm on Arch) and see if it makes any difference.
*** This bug has been marked as a duplicate of bug 457284 ***
Actually not a duplicate of that, as here the whole screen is black.
Some questions: - Does it happen when the system locks the screen? - Does it happen when the system puts the display to sleep? - Does it happen when the system suspends? - Are there more than one screen? - Are there more than one GPU? - Is it a PRIME system with muxing? If so, which GPU was driving the display? - Is the cursor visible? - Are there any GUI elements visible? - Is the broken lock screen function (e.g. blindly typing your password and hitting Enter unlocks)? - Is there a method that brings you back to a working desktop (e.g. killing kscreenlocker_greet). - Is the desktop session using X11 or Wayland?
(In reply to Nate Graham from comment #31) >- Does it happen when the system locks the screen? I think only when put the display to sleep, but i'm not 100% sure >- Does it happen when the system puts the display to sleep? Yes >- Does it happen when the system suspends? No, suspend is disabled on my system. >- Are there more than one screen? Yes, I have 2 4K monitor >- Are there more than one GPU? I have an nvidia 3090 card, but there is also a Radeon 580X as secondary card, but it's under vfio to be used inside VMs, so i don't think it's the problem. >- Is it a PRIME system with muxing? If so, which GPU was driving the display? No, it isn't a PRIME system. >- Is the cursor visible? Yes >- Are there any GUI elements visible? No >- Is the broken lock screen function (e.g. blindly typing your password and hitting Enter unlocks)? I tried without success, but because is everything black i can't say for sure. >- Is there a method that brings you back to a working desktop (e.g. killing kscreenlocker_greet). Not sure, I just reboot the PC when it happen. >- Is the desktop session using X11 or Wayland? The desktop is wayland, but SDDM should be X11 I'm not having this problem since the last 3/4 days (I had it also with RC1 at begin). But because it doesn't happen every time, i'm not sure if something is changed or was just a few lucky days. The only things I changed are distro updates (arch linux) and changed the render loop from threaded to to basic inside "kcmshell6 kcm_qtquicksettings" (to work around a different bug)
In general, sometimes simply turning off and turning on the monitor using the monitor's power button helps. I saw this mentioned in some online chat. It turned out that this sometimes helps.
Thanks for the info!
I too have been affected by a probably different bug (no signal too monitor). As a result, I changed from auto hybrid-sleep to auto hibernate. Dunno maybe btrfs issue, but I'm using a swap partition. So below is now after hibernate but used to be after sleep mode too: Ok ok so I too have possibly been affected by this bug as well. 0. I however see the log screen where I use a slideshow of pictures as background. These pictures are seen but in the middle password field or my username don't show. Cursor however is active and in the middle where the pw field is supposed to show, the arrow of the cursor changed to a pipe so I know where to activate the not-shown pw field. So I left click there, type my pw and hit enter. That way I know I have unlocked the session which however is still visually covered with the lock screen. In the middle the cursor arrow does not change to pipe now. My workaround then is: 1./0b. Wait a few minutes, up to 6-7. or which I mostly after 0. 2. Change into TTY3 and back. If I get the black screen with only cursor like the OP: 2b. Change into TTY3 and log into it and look at htop, hit Q to quit it, look at nvtop (not installed by default) and hit Q and then I switch back to graphical interface from TTY3 (CTRL+ALT+F2). In either of the monitors shown in TTY you see the lockscreen process or plasmashell above 80%. For me this eventually changes after waiting a while. If I still get the black screen with only cursor like the OP. 2c. Repeat 2b Might be the switching to TTY and back triggers the graphics to be restarted faster. At least I get my session back and the info message in systray: Your graphics had to be restarted due to a graphical issue (or a wording the like). And here everything works again as expected, full GUI. (Apart from some screen tearing when switching between Activities or in FF Yt videos, which is why I usually log out and back in in these restored/unlocked sessions). Everyone is welcome to translate my complicatedly described workaround into fewer, better organized sentences :)
And X11 btw ^
(In reply to holyzolly from comment #35) > I too have been affected by a probably different bug (no signal too monitor). > As a result, I changed from auto hybrid-sleep to auto hibernate. Dunno maybe > btrfs issue, but I'm using a swap partition. > So below is now after hibernate but used to be after sleep mode too: > > Ok ok so I too have possibly been affected by this bug as well. > 0. I however see the log screen where I use a slideshow of pictures as > background. These pictures are seen but in the middle password field or my > username don't show. Cursor however is active and in the middle where the pw > field is supposed to show, the arrow of the cursor changed to a pipe so I > know where to activate the not-shown pw field. So I left click there, type > my pw and hit enter. That way I know I have unlocked the session which > however is still visually covered with the lock screen. In the middle the > cursor arrow does not change to pipe now. > My workaround then is: > 1./0b. Wait a few minutes, up to 6-7. > or which I mostly after 0. > 2. Change into TTY3 and back. If I get the black screen with only cursor > like the OP: > 2b. Change into TTY3 and log into it and look at htop, hit Q to quit it, > look at nvtop (not installed by default) and hit Q and then I switch back to > graphical interface from TTY3 (CTRL+ALT+F2). In either of the monitors shown > in TTY you see the lockscreen process or plasmashell above 80%. For me this > eventually changes after waiting a while. If I still get the black screen > with only cursor like the OP. > 2c. Repeat 2b > > Might be the switching to TTY and back triggers the graphics to be restarted > faster. > At least I get my session back and the info message in systray: Your > graphics had to be restarted due to a graphical issue (or a wording the > like). And here everything works again as expected, full GUI. (Apart from > some screen tearing when switching between Activities or in FF Yt videos, > which is why I usually log out and back in in these restored/unlocked > sessions). > > Everyone is welcome to translate my complicatedly described workaround into > fewer, better organized sentences :) In general, sometimes simply turning off and turning on the monitor using the monitor's power button helps.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5144
Git commit 6b4018014ca4dfe170d2ddab3873222acc3edcf0 by David Redondo. Committed on 08/02/2024 at 13:29. Pushed by vladz into branch 'master'. Guard against render time query failing glGetQuery can fail (for example because of a context loss) in this case the buffer stays unmodified. In this case this is zero resulting in GLRenderTimeQuery::result() returning a negative value. Down the line this leads to a negative duration in the RenderJournal and RenderLoopPrivate::scheduleRepaint starting a timer with an amount of milliseconds bigger than what an int can hold. This will not actually start a timer but QTimer::isActive returns true resulting in no futher repaints being scheduled. FIXED-IN: 6.0 M +3 -0 src/opengl/glrendertimequery.cpp https://invent.kde.org/plasma/kwin/-/commit/6b4018014ca4dfe170d2ddab3873222acc3edcf0
Git commit c34aec1c7bee25b822552df4cc873f827bf84892 by David Redondo. Committed on 08/02/2024 at 13:53. Pushed by davidre into branch 'Plasma/6.0'. Guard against render time query failing glGetQuery can fail (for example because of a context loss) in this case the buffer stays unmodified. In this case this is zero resulting in GLRenderTimeQuery::result() returning a negative value. Down the line this leads to a negative duration in the RenderJournal and RenderLoopPrivate::scheduleRepaint starting a timer with an amount of milliseconds bigger than what an int can hold. This will not actually start a timer but QTimer::isActive returns true resulting in no futher repaints being scheduled. FIXED-IN: 6.0 (cherry picked from commit 6b4018014ca4dfe170d2ddab3873222acc3edcf0) M +3 -0 src/opengl/glrendertimequery.cpp https://invent.kde.org/plasma/kwin/-/commit/c34aec1c7bee25b822552df4cc873f827bf84892
*** Bug 477738 has been marked as a duplicate of this bug. ***
*** Bug 478090 has been marked as a duplicate of this bug. ***
I see that similarly named bugs for Wayland are being merged into this one as duplicates, but I'm still getting this issue with the referenced commit after suspending the Wayland session. Turning the monitor off and on again with the physical button helped just now. Operating System: openSUSE Tumbleweed 20240208 KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.1 Kernel Version: 6.7.4-1-default (64-bit) Graphics Platform: Wayland Processors: 32 × Intel® Core™ i9-14900K Graphics Processor: NVIDIA GeForce RTX 4070/PCIe/SSE2 (driver version: 545.29.06)
UPD. Unless these are coincidences, I think: 1) This is now only reproducible with automatic (timer-based) suspend. If I invoke the suspend mode manually, then graphics is restored correctly. (I use the default energy saving settings) 2) Turning the monitor off and on again with the hardware button is a reliable workaround for me (thanks, Victor!)
My mistake, the Wayland issues are different and should not have been duped to this one. I'll un-dupe them, and we'll continue to track those separately.