Created attachment 130355 [details] Sidebarview is not there SUMMARY When I suspend the pc and then log back in after some hours, sidebarview on system settings does not render at all, leaving a black square instead STEPS TO REPRODUCE 1. Suspend 2. log back in 3. open system settings OBSERVED RESULT There is a black square where sidebarview would be EXPECTED RESULT sidebarview is there System specs and os Operating System: Arch Linux KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 Kernel Version: 5.7.9-arch1-1 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4820K CPU @ 3.70GHz Memory: 13.6 GiB of RAM Graphics Processor: GeForce GTX 1050 Ti/PCIe/SSE2 ADDITIONAL INFORMATION Sidebarview does appear when I go directly to theme settings, even if the rest of settings do not render sidebarview, theme settings does for some reason. Restarting plasmashell and kwin does not resolve the issue, only way to get sidebarview back is to reboot. My system has up to date nvidia drivers
Seems similar to Bug 364766, though that's supposed to have been fixed with the latest NVIDIA drivers. Erik, any ideas?
Driver version is 450.57
Possibly also related to https://bugs.kde.org/show_bug.cgi?id=424311 Out of curiosity, are you using a PRIME / hybrid graphics setup? I'm wondering if the issue is specific to such systems, as I've been using the 450.57 driver for a while and haven't noticed the issue personally (with dedicated graphics only).
> only way to get sidebarview back is to reboot. Not even just closing systemsettings and reopening? That sidebar is a QQuickWidget which is a bit problematic with regards to the resetting as it spans across multiple paths. We do reset the backing FBO when the main page starts to render, but we can't trigger a reset from the QWidget doing the final rendering. Potentially a port to embedded windows instead of QQuickWidget will resolve this.
Reopening does not fix it, only thing that restored it is rebooting. My question is: why does the theme setting page always has it working? Using single graphics card
Exactly the same problem for me nvidia-driver 450.57 in PRIME mode. So basically nvidia is always enabled and renders everything. (Intel can't render on second monitor, so I don't use it). Even being black the sidebar is still clickable, but it's totally black all the time. 100% reproducible. always after resume but never after reboot. parameters passed to nvidia kernel module: options nvidia \ NVreg_DeviceFileGID=27 \ NVreg_DeviceFileMode=432 \ NVreg_DeviceFileUID=0 \ NVreg_ModifyDeviceFiles=1 \ NVreg_PreserveVideoMemoryAllocations=1 \ NVreg_TemporaryFilePath=/tmp nvidia suspend/resume systemd services are enabled and according to the logs are properly executed. restarting plasma settings has no any effect on this problem. disabling dekstop effects support has no any effect on this problem. playing with effects renderer selection has no any effect on this problem. changing different windows decorations/widgets style etc has no any effect on this problem. I often update my gentoo system and probably the problem was first time noticed not more than a month ago. plasma 5.19.4 qt 5.15.0 kernel 5.7.11 nvidia GeForce GTX 1660 Ti Mobile btw Google Chrome usually also has problems with resume. But restarting it helps.
I confirm the relevance to https://bugs.kde.org/show_bug.cgi?id=424311 After downgrading nvdia-driver to 440.100 I don't see the black sidebar after resume anymore.
*** This bug has been marked as a duplicate of bug 424311 ***
I'll try and upgrade and hope I can hit it
I now can reproduce it. It's local to systemsettings, so not a kwin bug. It seems in our first call to qopenglcontext->create() the m_getGraphicsResetStatus returns 0x92BB even though we've just started! Like it's not reset after suspend or something. What's interesting is that simply calling m_getGraphicsResetStatus(); once earlier fixes it. This only seems to affect the systemsettings because QQuickWindow has and offscreen surfaces don't really handle the reset in a way that triggers a repaint. and only on the sidebar because it's the first glcontext and as mentioned above simply calling getGraphicsResetStatus once seems to clear it. That hints towards an nvidia bug, but hopefully now we have something we can reproduce in a test case more easily.
Created attachment 131075 [details] Test case of the bug at hand Report for the nvidia people: Attached is a test case that creates a context and immediately calls glGetGraphicsResetStatusARB() On boot if I run this as an application I get GL_NO_ERROR and this app will quit and exit. This happens for every time the program is run - as expected. Now with this program *NOT RUNNING* suspend and resume. Every new invocation of the app will print "Graphics reset status! : 37563" This appears to be new with nvidia 450. Subsequent calls appear to be correct, but it still doesn't make sense for us to be told context has been lost when it wasn't lost whilst we were running.
Dang. Yes, this is indeed a regression in the 450 NVIDIA driver. Thank you for narrowing it down, David. I've identified the root cause and will try to get a fix included in the next minor version.
*** Bug 426854 has been marked as a duplicate of this bug. ***
If anyone needs a temporary workaround; kcmshell5 qtquicksettings set the backend to software
(In reply to Erik Kurzinger from comment #3) > Out of curiosity, are you using a PRIME / hybrid graphics setup? I am using a desktop computer with dedicated 1060 6GB Graphics Card.
As a temporary workaround, if you need to use system settings you can enter the global theme settigs from search and sidebar should render correctly. Don't know but somehow it works that way.
*** Bug 426383 has been marked as a duplicate of this bug. ***
*** Bug 428874 has been marked as a duplicate of this bug. ***
*** Bug 429355 has been marked as a duplicate of this bug. ***
*** Bug 430383 has been marked as a duplicate of this bug. ***
*** Bug 430264 has been marked as a duplicate of this bug. ***
*** Bug 431209 has been marked as a duplicate of this bug. ***