SUMMARY After waking from sleep, Plasmashell is unusable with graphical glitches. It does appear to respond to keypresses, but I can't see what's going on. STEPS TO REPRODUCE 1. Log in to a Wayland session 2. Set machine to sleep after some idle time 3. Wake machine from sleep and login OBSERVED RESULT **See attachment** Sometimes after waking from sleep, the lock screen is not visible - however it also appears to respond to key presses allowing you to login. EXPECTED RESULT Log in and session is resumed as per X11. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.1-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2 ADDITIONAL INFORMATION
Created attachment 145691 [details] plasma wayland after sleep
Moving to KWin as this can't be a Plasma problem. It could be an NVIDIA GU driver problem though. Are you able to test with the Plasma 5.24 beta? A lot of graphical fixes made it into that release.
Looks like a regression after the nvidia qtwayland patch.
Which one? Is it a KWin issue or a Qt issue or an NVIDIA issue? But I don't see how it can be a Plasma issue; moving to KWin.
But more importantly: Matty, are you still able to reproduce this issue with Plasma 5.27, the latest NVIDIA drivers, and Qt 5.15.9?
(In reply to Nate Graham from comment #5) > But more importantly: Matty, are you still able to reproduce this issue with > Plasma 5.27, the latest NVIDIA drivers, and Qt 5.15.9? This is indeed still occurring. Nvidia version: 530.41.03 Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.2.12-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2
Created attachment 158510 [details] nvidia glitch after waking from sleep 28 APR 2023
Ouch. Thanks for confirming.
*** Bug 473819 has been marked as a duplicate of this bug. ***
I have also experienced this issue described my duplicate bug 473819, which was from a fresh install this weekend (27/8). The difference to me is that I doesn't put my computer to sleep, only the monitors when inactive for too long.
(In reply to Nate Graham from comment #8) > Ouch. Thanks for confirming. This ticket was opened in January 2022 and I stumbled on the same/similar problem with a fresh Fedora 38 KDE install a week ago. Is this prioritized at all? It's there any workarounds for this problem that means not having to disable that the monitors go to sleep after user inactivity?
I'm facing the same issue on the following system: Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-32-generic (64-bit) Graphics Platform: Wayland Processors: 16 × 11th Gen Intel® Core™ i7-11800H @ 2.30GHz Memory: 15.4 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3050 Ti Laptop GPU/PCIe/SSE2
Hi I experienced the same Bug but was able to resolve it with the help of "https://forum.endeavouros.com/t/graphic-bugs-after-sleep-kde-wayland-nvidia/46703/2" The solution is to preserve video memory after suspend. Detailed instructions for arch based systems can be found here: "https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks" under point 10. Another temporary fix is to run "plasmashell --replace" in krunner An observation that I made is, that this bug only occurs when I'm logged in and the PC is suspended. When no user is logged in, I had no issues. Hope this helps to narrow down the issue.
(In reply to Finn from comment #13) > Hi I experienced the same Bug but was able to resolve it with the help of > "https://forum.endeavouros.com/t/graphic-bugs-after-sleep-kde-wayland-nvidia/ > 46703/2" > > The solution is to preserve video memory after suspend. Detailed > instructions for arch based systems can be found here: > "https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks" under point 10. > > Another temporary fix is to run "plasmashell --replace" in krunner > > An observation that I made is, that this bug only occurs when I'm logged in > and the PC is suspended. When no user is logged in, I had no issues. > > Hope this helps to narrow down the issue. When using the term suspend, that means when the computer is put to sleep? I'm wondering if this could help the issue for me, for when the *monitors* wake up. I never put my computer to sleep
My current solution is from the login screen via SDDM select X11 instead of Wayland. NVIDIA drivers doesn't seem to like Wayland.
Does anyone still experience this issue after configuring nvidia to preserve video memory after suspend? (https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks) I also had similar problems, which disappeared after enabling this. If not, should this be closed as RESOLVED-DOWNSTREAM (since we are expecting distributions to have the correct configurations)?
(In reply to fanzhuyifan from comment #16) > Does anyone still experience this issue after configuring nvidia to preserve > video memory after suspend? > (https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks) I also had similar > problems, which disappeared after enabling this. > > If not, should this be closed as RESOLVED-DOWNSTREAM (since we are expecting > distributions to have the correct configurations)? Why does this mean there is no issue with kwin? And why do you call an experimental workaround "the correct configuration"?
(In reply to Dick Tracey from comment #17) > (In reply to fanzhuyifan from comment #16) > > Does anyone still experience this issue after configuring nvidia to preserve > > video memory after suspend? > > (https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks) I also had similar > > problems, which disappeared after enabling this. > > > > If not, should this be closed as RESOLVED-DOWNSTREAM (since we are expecting > > distributions to have the correct configurations)? > > Why does this mean there is no issue with kwin? I am not saying that there is no issue with kwin. I honestly don't know. That's why I am asking a question -- if this doesn't happen when nvidia is configured to preserve video memory after suspend, what would be the correct way to proceed? Does this means that distributions should always enable this option? Or should kwin handle this somehow? If so, how should kwin handle this? I don't know what the answer is. Someone more knowledgeable about these matters should comment. > And why do you call an experimental workaround "the correct configuration"? True, this feature is documented as experimental in the official nvidia documentation[1]. But it seems to be the only way provided by nvidia to save and restore all video memory allocations. Again, I am happy to hear your constructive feedback on this. [1] http://download.nvidia.com/XFree86/Linux-x86_64/545.29.06/README/powermanagement.html
The bug is not solved by enabling the nvidia suspend thing. I experience this problem when the monitors turn off by the energy saving setting while the computer is still on, not by suspending the entire computer.
(In reply to Dennis from comment #19) > The bug is not solved by enabling the nvidia suspend thing. I experience > this problem when the monitors turn off by the energy saving setting while > the computer is still on, not by suspending the entire computer. Humm do you also see this if you set the "when locked, turn off screen" to 10 sec and then lock your computer and wait 10 seconds for the screen to turn off? I wanted to double check because by default, the energy saving setting also puts the computer to sleep after 15 min of inactivity, which may be triggering in your case. It would also be great if you could provide the output of `journalctl -b` when you see this again. Thanks!
(In reply to fanzhuyifan from comment #20) > (In reply to Dennis from comment #19) > > The bug is not solved by enabling the nvidia suspend thing. I experience > > this problem when the monitors turn off by the energy saving setting while > > the computer is still on, not by suspending the entire computer. > > Humm do you also see this if you set the "when locked, turn off screen" to > 10 sec and then lock your computer and wait 10 seconds for the screen to > turn off? I wanted to double check because by default, the energy saving > setting also puts the computer to sleep after 15 min of inactivity, which > may be triggering in your case. > > It would also be great if you could provide the output of `journalctl -b` > when you see this again. > > Thanks! Yes. My test case: logging to KDE with Wayland, go to System Settings > Power Management > Energy Saving and set "Screen Energy Saving" to "1 min". I wait for the screens to turn off into stand-by. Then after a few seconds I move the mouse again to wake them up. This is when the entire desktop is black, windows are glitchy, taskbar is semi-broken.
Created attachment 163546 [details] Journalctl log when the screen energy saver activates
Would plasmashell becoming unresponsive after resume from S3 sleep on X11 be related? I did have such issue and was wondering what the problem is. Then I checked Arch Wiki. From https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks Quote: "Note: Contrary to NVIDIA's instructions, it is currently not necessary to enable nvidia-resume.service (and it is in fact probably not a good idea to enable it), because the /usr/lib/systemd/system-sleep/nvidia script does the same thing as the service (but slightly earlier), and it is enabled by default (systemd calls it after waking up from a suspend). Only enable nvidia-suspend.service and/or nvidia-hibernate.service, unless you are using GDM with Wayland which requires nvidia-resume.service too." So I have disabled nvidia-resume.service and havent had to do "plasmashell --replace" ever since. Operating System: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 Kernel Version: 6.6.4-273-tkg-bore (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 62.2 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82B1 System Version: Lenovo Legion 5 15ARH05H RTX 2060 Mobile (0x1f15)
(In reply to petrk from comment #23) > Would plasmashell becoming unresponsive after resume from S3 sleep on X11 be > related? > I did have such issue and was wondering what the problem is. Then I checked > Arch Wiki. There is also a separate bug report about X11: https://bugs.kde.org/show_bug.cgi?id=475605
Nevermind, it just took longer sleep to trigger. Ignore my previous comment.
even after update my system to plasma 6.0.3 the issue si still there Operating System: EndeavourOS KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.2-zen2-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.4 Gio of RAM Graphics Processor: NVIDIA GeForce GTX 1650/PCIe/SSE2
For anyone who was experiencing this issue in the past, did the 555 driver series fix it?
Still experiencing this on 555.52.04 with plasma 6.1 Operating System: Arch Linux KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Kernel Version: 6.9.5-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2
happening on 555.58 as well
I can confirm that it still happens on Plasma 6.1.2 even after enabling nvidia-suspend.service. After enabling nvidia-suspend.service graphical glitches appear less than before but it's still unusable as it is for now. Guess I'll have to disable suspend to RAM until NVIDIA or KDE fixes the problem... Operating System: Arch Linux KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-4670K CPU @ 3.40GHz Memory: 11.4 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2
*** Bug 491032 has been marked as a duplicate of this bug. ***
Hi. My Linux crashed because of this... First, KDE crashed Then it entered the lock screen and the lock screen crashed. With the words: loginctl unlock-session 2 journalctl -xb systemctl reboot Reboot failed. Had to press ALT+CRTL+DELETE The shutdown was almost stable, with a console and text. I just thought for a long time about systemctl A reboot occurred, in which there were only tty consoles I had to roll back using TimeShift. Some data was deleted. It was KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2. Now KDE 6.1.1 KDE Frameworks 6.3.0 QT 6.7.2 And now everything is stable... And I repeat once again - there was no SLEEP mode. There was only a blocking and maybe a SCREEN DREAM.
(In reply to Maybeaday from comment #32) > Hi. > > My Linux crashed because of this... > First, KDE crashed > Then it entered the lock screen and the lock screen crashed. > > With the words: loginctl unlock-session 2 > journalctl -xb > systemctl reboot > > Reboot failed. Had to press ALT+CRTL+DELETE > The shutdown was almost stable, with a console and text. > I just thought for a long time about systemctl > > A reboot occurred, in which there were only tty consoles > > I had to roll back using TimeShift. > Some data was deleted. > > It was > KDE Plasma Version: 6.1.3 > KDE Frameworks Version: 6.4.0 > Qt Version: 6.7.2. > > Now > KDE 6.1.1 > KDE Frameworks 6.3.0 > QT 6.7.2 > > And now everything is stable... > > And I repeat once again - there was no SLEEP mode. > There was only a blocking and maybe a SCREEN the screen.
> I can confirm that it still happens on Plasma 6.1.3 even after enabling nvidia-suspend.service. After enabling nvidia-suspend.service graphical glitches appear less than before but it's still unusable as it is for now. same as @juan Operating System: EndeavourOS KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-arch1-1 (64-bit) Graphics Platform: Wayland
I'm also experiencing this issue.
Confirming +1. Option in the nvidia kernel module is enabled: NVreg_PreserveVideoMemoryAllocations=1 All the nvidia-suspend/resume/hibernate systemd services are enabled. On X11, computer resumes from sleep properly with SDDM lock screen. On Wayland, it takes a minute to come up with a graphical mess. It is possible to log in (ignoring the garbled graphics) but then I have to CTRL+ALT+DEL to log out from the account and log back in to make the graphics working again. Operating System: Arch Linux KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2 Manufacturer: ASUS
This has fixed most of my issues when waking up. # /etc/modprobe.d/nvidia.conf options nvidia-drm modeset=1 options nvidia_drm fbdev=1 options nvidia NVreg_EnableGpuFirmware=0
This is a NVidia driver issue, you can work around it by setting up the driver with that NVreg_PreserveVideoMemoryAllocations option. We have that in our packaging recommendations (https://community.kde.org/Distributions/Packaging_Recommendations), so there's nothing more we can do here
Hi, I had to do a fresh install of my OS (Endeavor OS) after which I no longer face the problem described, although the workaround suggested here is not applied completly. The system-d services are running but `NVreg_EnableGpuFirmware` is not set actively . To test this I checked `cat /proc/cmdline` and my modeporbe folder for a mention of `NVreg_EnableGpuFirmware`. I did not find it. And I guess that the default is `0`. The driver I am using is `560.35.03-17`. On the following system: Operating System: EndeavourOS KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3070/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. System Version: 6.0 Can anyone else confirm that this has been fixed in such a way that no workaround is required?