Bug 424311

Does it affect a clean new user session?

(In reply to David Edmundson from comment #1)
> Does it affect a clean new user session?

Yep, same behaviour.

I've also tried other things like disabling triple buffering (as that was something mentioned that might break with later driver versions) as well as switching to EGL. I can't find any combination of settings that works properly still. This is still an issue with the latest Nvidia driver and kernel (both updated since my original report). And I've verified to be absolutely sure, downgrading back to the 440 driver (I tried just now with 440.82) completely fixes the issue. Compositing works perfectly on 440 with identical settings that are broken on 450. Any additional troubleshooting tips would be appreciated as it would be nice to be able to use the 450 driver.

Can you please run kwin as `env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace` from terminal and post the output here? Please make sure that the provided output contains no sensitive or confidential data.

*** Bug 424592 has been marked as a duplicate of this bug. ***

*** Bug 424681 has been marked as a duplicate of this bug. ***

There's some fairly detailed information in duped Bug 424311.

@Vlad
Here is the output you requested;

kwin_scene_opengl: Initializing OpenGL compositing
QGLXContext: Failed to create dummy context
No provider of glXCreateContextAttribsARB found.  Requires one of:
    GLX_ARB_create_context
Application::crashHandler() called with signal 6; recent crashes: 1
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kwin_x11 path = /usr/bin pid = 1247424
KCrash: Arguments: /usr/bin/kwin_x11 --replace 
KCrash: Attempting to start /usr/lib/drkonqi
kwin_core: Compositing is not possible

[1]+  Stopped                 env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace

Please feel free to request further info.

(In reply to Vlad Zahorodnii from comment #4)
> Can you please run kwin as `env KWIN_GL_DEBUG=1
> QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace` from
> terminal and post the output here? Please make sure that the provided output
> contains no sensitive or confidential data.

kwin_scene_opengl: Initializing OpenGL compositing
QGLXContext: Failed to create dummy context
No provider of glXCreateContextAttribsARB found.  Requires one of:
    GLX_ARB_create_context
Application::crashHandler() called with signal 6; recent crashes: 1
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kwin_x11 path = /usr/bin pid = 1247424
KCrash: Arguments: /usr/bin/kwin_x11 --replace 
KCrash: Attempting to start /usr/lib/drkonqi
kwin_core: Compositing is not possible

[1]+  Stopped                 env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace

Sorry didn't see there's actually a 'Reply' button.

Just wanted to confirm the issue and provide another data point for the requested command from Vlad:

env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace
Icon theme "gnome" not found.
kwin_scene_opengl: Initializing OpenGL compositing
QGLXContext: Failed to create dummy context
OpenGL vendor string:                   NVIDIA Corporation
OpenGL renderer string:                 GeForce GTX TITAN X/PCIe/SSE2
OpenGL version string:                  3.1.0 NVIDIA 450.57
OpenGL shading language version string: 1.40 NVIDIA via Cg compiler
Driver:                                 NVIDIA
Driver version:                         450.57
GPU class:                              Unknown
OpenGL version:                         3.1
GLSL version:                           1.40
X server version:                       1.20.8
Linux kernel version:                   5.6.18
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
kwin_scene_opengl: Initializing fences for synchronization with the X command stream
kwin_scene_opengl: 0x20071: Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) will use SYSTEM HEAP memory as the source for buffer object operations.
kwin_scene_opengl: 0x20071: Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) has been mapped WRITE_ONLY in SYSTEM HEAP memory (fast).
kwin_scene_opengl: OpenGL 2 compositing successfully initialized
kwin_scene_opengl: 0x20071: Buffer detailed info: Buffer object 2 (bound to GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
kwin_scene_opengl: 0x20092: Program/shader state performance warning: Vertex shader in program 1 is being recompiled based on GL state.

Also, running the above command broke my session and I had to reboot :(.

(resetting status)

Created attachment 130519 [details]
Screenshot of compositor working under same Nvidia graphics driver, whereas before reboot it did not work.

This is a screenshot of the settings screens in Plasma showing data whereas before there was only a black box. I simply ran the command `env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace`and restarted the system and now it works.

Looks like the behavior was temporary. I'm having the issue once again as the original bug post. The navigation pane of my Plasma settings apps are now solid black. I apologize for bumping this bug so many times.

Here's the output I get with Vlad's suggested command.

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 180, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.Disconnected", "Not connected to D-Bus server")
kwin_scene_opengl: Initializing OpenGL compositing
QGLXContext: Failed to create dummy context
No provider of glXCreateContextAttribsARB found.  Requires one of:
    GLX_ARB_create_context
Application::crashHandler() called with signal 6; recent crashes: 1
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kwin_x11 path = /usr/bin pid = 2624
KCrash: Arguments: /usr/bin/kwin_x11 --replace 
KCrash: Attempting to start /usr/lib/drkonqi
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 180, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 180, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 12582919, major code: 20 (GetProperty), minor code: 0
Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.Disconnected", "Not connected to D-Bus server")
kwin_core: Compositing is not possible

Looks like the behavior was temporary. I'm having the issue once again as the original bug post. The navigation pane of my Plasma settings apps are now solid black. I apologize for bumping this bug so many times.

Quick update, this appears to be solely an Arch Linux issue. I spoke with Nvidia support and they said they could not replicate the issue. They were using Ubuntu so I made space for another install out of curiosity. On the same laptop with the same 450.57 driver and KDE, there are no issues with compositing at all on Ubuntu.

@Arix Perhaps it's a kernel issue? I'm sure Ubuntu is not using the latest kernel. Could you confirm your Ubuntu kernel? Currently Arch is at 5.7.12.

(In reply to br1ghtch1p from comment #17)
Possibly. I think their kernel was all the way back on 5.4. I had the same thought, and tried a couple different kernels on Arch yesterday, like Zen, and the 5.8 testing kernel. No luck. I was going to try 5.4 just now but the nvidia module won't rebuilt due to mismatching gcc, and setting the environment variable to the older gcc or ignoring it altogether wasn't working for some reason. Anyway, I'd imagine that this may be out of KDE's control, especially given all of the particulars involved. I'll attempt to continue correspondence with Nvidia though, hopefully they can try to replicate the problems under Arch.

I was able to convince Nvidia to test the 450 driver with an Archlinux setup. They are now confirming they are reproducing the issues being discussed here so hopefully we'll get a fix on the next nvidia update.

It does seem to point to the newer kernel against the 450.

Created attachment 130816 [details]
0001-Use-glXGetProcAddress-for-context-creation.patch

This was reported downstream a while ago and I have a theory: https://bugzilla.opensuse.org/show_bug.cgi?id=1174498#c9

Can the issue be reproduced with 0001-Use-glXGetProcAddress-for-context-creation.patch applied to kwin?

The kscreenlocker issue is the same, but mitigated by dropping the sandbox.

Setting needsinfo.

Same issues here:
- system settings displays black box to the left
- screen locker only shows mouse cursor, have to unlock manually from console

Patch '0001-Use-glXGetProcAddress-for-context-creation.patch' does not seem to have any effect.

Gentoo Linux (amd64, stable)
Linux Kernel 5.4.48
NVIDIA drivers 450.57
KWin 5.18.5
Qt 5.14.2

(In reply to Fonic from comment #22)
> Same issues here:
> - system settings displays black box to the left
> - screen locker only shows mouse cursor, have to unlock manually from console
> 
> Patch '0001-Use-glXGetProcAddress-for-context-creation.patch' does not seem
> to have any effect.
> 
> Gentoo Linux (amd64, stable)
> Linux Kernel 5.4.48
> NVIDIA drivers 450.57
> KWin 5.18.5
> Qt 5.14.2

Yeah, the patch will only fix kwin_x11 crashes.

For kscreenlocker, https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/9 might've worked around this as well.

I installed the patch to kwin package and it doesn't seem to work. kwin still crashes upon wakeup after putting system to sleep.

OS: Arch Linux
Kernel: x86_64 Linux 5.8.1-arch1-1
DE: KDE 5.73.0 / Plasma 5.19.4
GPU: Quadro P2000

For confirmation, are you supposed to apply the patch to kwin's source file? I wasn't flagged any errors when I did so.

(In reply to br1ghtch1p from comment #24)
> I installed the patch to kwin package and it doesn't seem to work. kwin
> still crashes upon wakeup after putting system to sleep.
> 
> OS: Arch Linux
> Kernel: x86_64 Linux 5.8.1-arch1-1
> DE: KDE 5.73.0 / Plasma 5.19.4
> GPU: Quadro P2000
> 
> For confirmation, are you supposed to apply the patch to kwin's source file?
> I wasn't flagged any errors when I did so.

You'll have to apply the patch to the source tree and then build and install it.

(In reply to Fabian Vogt from comment #25)
> (In reply to br1ghtch1p from comment #24)
> > I installed the patch to kwin package and it doesn't seem to work. kwin
> > still crashes upon wakeup after putting system to sleep.
> > 
> > OS: Arch Linux
> > Kernel: x86_64 Linux 5.8.1-arch1-1
> > DE: KDE 5.73.0 / Plasma 5.19.4
> > GPU: Quadro P2000
> > 
> > For confirmation, are you supposed to apply the patch to kwin's source file?
> > I wasn't flagged any errors when I did so.
> 
> You'll have to apply the patch to the source tree and then build and install
> it.



I applied the patch via Arch PKGBUILD and built it from there. I'll download the source and apply the patch and see if that works that way.

(In reply to Fabian Vogt from comment #25)
> (In reply to br1ghtch1p from comment #24)
> > I installed the patch to kwin package and it doesn't seem to work. kwin
> > still crashes upon wakeup after putting system to sleep.
> > 
> > OS: Arch Linux
> > Kernel: x86_64 Linux 5.8.1-arch1-1
> > DE: KDE 5.73.0 / Plasma 5.19.4
> > GPU: Quadro P2000
> > 
> > For confirmation, are you supposed to apply the patch to kwin's source file?
> > I wasn't flagged any errors when I did so.
> 
> You'll have to apply the patch to the source tree and then build and install
> it.



I applied the patch to the source tree for kwin-5.19.4 but no luck. I still get kwin crashing on wakeup from suspend. I'm not entirely sure why it works for you and not for me. Perhaps a different kernel?

Same issue here since some weeks. Black System Settings naviagion and kscreensaver/lockscreen freezes my desktop randomly, only killing the session helps. I have disabled it for now.

System: Arch, KDE-Plasma, Nvidia 1070, ryzen 3950, linux-ck-zen2 kernel, newest updates and newest drivers.

The issue is still visible after applying the patch from comment 20; setting status.

Are you certain this is a regression in the 450.57 driver? We've reproduced the issue internally at NVIDIA, but also observe similar corruption with a 440 series driver.

It is possible the regression was actually caused by another package that just happened to be updated around the same time? One of KDE's components, Qt, or the kernel might be suspects.

(In reply to Erik Kurzinger from comment #30)

I've downgraded and re-upgraded on a couple different occasions to verify that it is the driver. No other packages were changed, and it has consistently been fine on 440 and broken on 450. As I beleive I mentioned above as well, I've noticed issues in another compositor, Picom, when using GLX but again only on the 450 driver. So it's not just a KDE/kwin thing. This is again something that works with no issues on 440, all other packages untouched.

(In reply to Erik Kurzinger from comment #30)
> Are you certain this is a regression in the 450.57 driver? We've reproduced
> the issue internally at NVIDIA, but also observe similar corruption with a
> 440 series driver.
> 
> It is possible the regression was actually caused by another package that
> just happened to be updated around the same time? One of KDE's components,
> Qt, or the kernel might be suspects.



I have the same experience with Arix. I've tested downgrade to 440 without any issues. It also seem to points solely to the compositors since issues with kscreenlocker, at least in my system, seem to have been resolved. Since its the compositor, it looks like an issue with the GLX in the 450 driver.

Just tested nvidia driver 450.66. All issues still present after suspend, i.e.

- kscreenlocker only display mouse cursor (always)
- system settings displays black box to the left (always)
- kwin crashes (always)
- graphical glitches like blinking parts on second screen (sometimes)

That driver really is a glitchfest. Not to mention that it also forces you to disable security features like AMD SME because they don't support it.

It's about time NVIDIA moved their driver in-tree like everyone else, so incompatibilites are detected and solved during development.

I can also confirm the update to 450.66 doesn't have an effect on the problem. Kwin still crashes on resume from suspend.

And I can confirm that downgrading of the nvidia driver actually works.

In my case, I downgraded to 440.100 (latest stable version of 440 branch on Gentoo Linux) and all issues are gone. When suspending/resuming now,
- kscreenlocker works as expected
- system settings works as expected
- kwin (*) does not crash
- there are no graphical glitches

(*) Patch '0001-Use-glXGetProcAddress-for-context-creation.patch' *not* applied

Gentoo Linux (amd64, stable)
Linux Kernel 5.4.48
NVIDIA drivers 440.100
KWin 5.18.5
Qt 5.14.2

Today, I updated packages again and now logging in results in plasmashell experiencing a segfault.

(In reply to evilsourcerer from comment #36)
> Today, I updated packages again and now logging in results in plasmashell
> experiencing a segfault.

Which packages were updated? Are you in Arch?

Never mind, apparently it's an unrelated issue. QT5 updated, which broken the Event Calendar widget in KDE, and caused a segfault similar to the one described by the issue.

Hello,

In my case (Kubuntu 20.10, driver 450.66, kernel 5.8.0-18) I experience no issue but a black screen after standby, with only the mouse visible, and the ability to switch to another TTY and login from there. Nouveau works fine.
I don't know if it's related.

(In reply to Lapineige from comment #39)
> Hello,
> 
> In my case (Kubuntu 20.10, driver 450.66, kernel 5.8.0-18) I experience no
> issue but a black screen after standby, with only the mouse visible, and the
> ability to switch to another TTY and login from there. Nouveau works fine.
> I don't know if it's related.

It is related. I occasionally get the same symptom. It is kwin crashing on wakeup. Nouveau of course is not using a compositor or a different compositor. You can experiment by disabling compositor in KDE and going to standby and see if you still get the black screen. I'm betting you won't.

Just out of curiosity: is NVIDIA actually doing something about this?

Seems to be a recurring pattern with NVIDIA where they admit/know about bugs in their driver, but just don't care (e.g. bug preventing use of AMD SME).

(In reply to Fonic from comment #41)
> Just out of curiosity: is NVIDIA actually doing something about this?
> 
> Seems to be a recurring pattern with NVIDIA where they admit/know about bugs
> in their driver, but just don't care (e.g. bug preventing use of AMD SME).

Yes I filed a bug and nvidia confirmed the problem exists. Here is transcript of last email:

-- I installed fresh Arch linux and can recreate issue every time I used inbuilt sleep command.

-- We are working on its fix and will keep you updated on the same.

and that's date 11 August.

I assume the fix will come on the next major update but when that will happen is everyone's guess. I don't think there's a testing driver yet - not that I know of anyway.

(In reply to br1ghtch1p from comment #40)
> (In reply to Lapineige from comment #39)
> > Hello,
> > 
> > In my case (Kubuntu 20.10, driver 450.66, kernel 5.8.0-18) I experience no
> > issue but a black screen after standby, with only the mouse visible, and the
> > ability to switch to another TTY and login from there. Nouveau works fine.
> > I don't know if it's related.
> 
> It is related. I occasionally get the same symptom. It is kwin crashing on
> wakeup. Nouveau of course is not using a compositor or a different
> compositor. You can experiment by disabling compositor in KDE and going to
> standby and see if you still get the black screen. I'm betting you won't.


I did test that: indeed, switching to Xrender instead of OpenGL "fix" the issue.

(In reply to br1ghtch1p from comment #42)
> (In reply to Fonic from comment #41)
> > Just out of curiosity: is NVIDIA actually doing something about this?
> > 
> > Seems to be a recurring pattern with NVIDIA where they admit/know about bugs
> > in their driver, but just don't care (e.g. bug preventing use of AMD SME).
> 
> Yes I filed a bug and nvidia confirmed the problem exists. Here is
> transcript of last email:
> 
> -- I installed fresh Arch linux and can recreate issue every time I used
> inbuilt sleep command.
> 
> -- We are working on its fix and will keep you updated on the same.
> 
> and that's date 11 August.
> 
> I assume the fix will come on the next major update but when that will
> happen is everyone's guess. I don't think there's a testing driver yet - not
> that I know of anyway.

When I reported the bug regarding AMD SME, it was exactly the same:
'We can confirm this bug.'
'We're working on it.'
'We'll keep you posted.'

What actually happened:
I only ever got updates after inquiring.
After 6 months, of mostly silence apart from 'we're still working on it', I got this answer: 'AMD SME is currently not supported. Our driver documentation advises users to disable that feature. We might support this in the future, but currently there is no timeline for this.'

Let's hope you have more luck.

Curious though:
How did you report the bug? There seems to be no bug tracker. I had to go through customer support back then.

(In reply to Fonic from comment #44)
> (In reply to br1ghtch1p from comment #42)
> > (In reply to Fonic from comment #41)
> > > Just out of curiosity: is NVIDIA actually doing something about this?
> > > 
> > > Seems to be a recurring pattern with NVIDIA where they admit/know about bugs
> > > in their driver, but just don't care (e.g. bug preventing use of AMD SME).
> > 
> > Yes I filed a bug and nvidia confirmed the problem exists. Here is
> > transcript of last email:
> > 
> > -- I installed fresh Arch linux and can recreate issue every time I used
> > inbuilt sleep command.
> > 
> > -- We are working on its fix and will keep you updated on the same.
> > 
> > and that's date 11 August.
> > 
> > I assume the fix will come on the next major update but when that will
> > happen is everyone's guess. I don't think there's a testing driver yet - not
> > that I know of anyway.
> 
> When I reported the bug regarding AMD SME, it was exactly the same:
> 'We can confirm this bug.'
> 'We're working on it.'
> 'We'll keep you posted.'
> 
> What actually happened:
> I only ever got updates after inquiring.
> After 6 months, of mostly silence apart from 'we're still working on it', I
> got this answer: 'AMD SME is currently not supported. Our driver
> documentation advises users to disable that feature. We might support this
> in the future, but currently there is no timeline for this.'
> 
> Let's hope you have more luck.
> 
> Curious though:
> How did you report the bug? There seems to be no bug tracker. I had to go
> through customer support back then.

Nvidia has a builtin bug report script packaged with the driver. Just run:
sudo nvidia-bug-report.sh

This will create a nvidia-bug-report.log.gz file. Just email this file and how to reproduce issue to this email: linux-bugs [ at ] nvidia [ dot ] com

It's probably good to have many people reporting the bug to be heard.

Update to NVIDIA driver 455.23.04, it seems that the compositor will no longer crash, however, the issue screenlocker and systemsettings still occurs.

I updated my system config by transferring old parameters (all ~/.xxx files), and used Nvidia drivers again (I did switch to nouveau to "solve" that black screen issue after standby), still 450.66, and the issue somewhat disappeared, not mater if I use the compositor or OpenGL/XRender.

(In reply to huyizheng from comment #46)
> Update to NVIDIA driver 455.23.04, it seems that the compositor will no
> longer crash, however, the issue screenlocker and systemsettings still
> occurs.

I updated to 455 as well but compositor still crashes on wakeup. Not exactly a bad crash - I just get a message desktop effects were restarted which is practically no change from former issue.

(In reply to Lapineige from comment #47)
> I updated my system config by transferring old parameters (all ~/.xxx
> files), and used Nvidia drivers again (I did switch to nouveau to "solve"
> that black screen issue after standby), still 450.66, and the issue somewhat
> disappeared, not mater if I use the compositor or OpenGL/XRender.

Edit: Sadly,the problem happens again.

To update, there *was* a driver regression which seems to be responsible for the symptoms described here. See https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the issue.

Unfortunately, I missed the deadline to get the fix into the 450.80 release yesterday. My apologies. However, it will be in the first official 455 release, which I believe is scheduled for Oct. 7. I've also back-ported it to the 450 branch, so it'll be in the *next* 450.xx release as well.

(In reply to Erik Kurzinger from comment #50)
> To update, there *was* a driver regression which seems to be responsible for
> the symptoms described here. See
> https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the
> issue.
> 
> Unfortunately, I missed the deadline to get the fix into the 450.80 release
> yesterday. My apologies. However, it will be in the first official 455
> release, which I believe is scheduled for Oct. 7. I've also back-ported it
> to the 450 branch, so it'll be in the *next* 450.xx release as well.

Archlinux has already updated to version 455. Will there be a subsequent update to realise the fix with those who are already in 455?

(In reply to br1ghtch1p from comment #51)
> (In reply to Erik Kurzinger from comment #50)
> > To update, there *was* a driver regression which seems to be responsible for
> > the symptoms described here. See
> > https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the
> > issue.
> > 
> > Unfortunately, I missed the deadline to get the fix into the 450.80 release
> > yesterday. My apologies. However, it will be in the first official 455
> > release, which I believe is scheduled for Oct. 7. I've also back-ported it
> > to the 450 branch, so it'll be in the *next* 450.xx release as well.
> 
> Archlinux has already updated to version 455. Will there be a subsequent
> update to realise the fix with those who are already in 455?

The current 455.23 driver is technically a beta release. The next 455.xx driver will be the official release, and will contain the fix. Arch is usually pretty quick about updating their package, so I assume it will land in the repos soon after it's posted.

Ok, now after updating to nvidia-455.28 there's no crashing when resuming from suspend and the black sidebar problem is fixed too. Thank you NVidia Linux people and plasma devs for solving this issue :)

Phew!

I updated and the system settings issue is still there for me. Using 1050ti. Double checked the nvidia driver, it is the new version 455.23.04-4, also rebooted after installing. Compositor is also buggy with the window decorations and suspend leaves a blinking cursor. I have an amd card now, so ill test tomorrow see if the problems are present with the amd card.

My mistake, seems .28 is still not yet rolled out, ill wait

I can confirm that the sidebar is fixed after resume from suspend. I can also run 
- env KWIN_GL_DEBUG=1 QT_LOGGING_RULES="kwin_scene_opengl.debug=true" kwin_x11 --replace

without the compositor crashing.
However I still get the notification on resume that desktop effects are restarted and I just wonder if this is now a normal message to expect on resume from suspend. For now I have muted out this notification.

(In reply to br1ghtch1p from comment #57)

> However I still get the notification on resume that desktop effects are
> restarted and I just wonder if this is now a normal message to expect on
> resume from suspend. For now I have muted out this notification.

Yeah I get that too every time I resume my computer from suspend. Is this normal behavior?

(In reply to sampingu02 from comment #58)
> (In reply to br1ghtch1p from comment #57)
> 
> > However I still get the notification on resume that desktop effects are
> > restarted and I just wonder if this is now a normal message to expect on
> > resume from suspend. For now I have muted out this notification.
> 
> Yeah I get that too every time I resume my computer from suspend. Is this
> normal behavior?

That's exactly my same question. I don't think the 440 driver had this issue but my intuition tells me this is probably the new normal for the current fix. At least now kwin doesn't crash on resume.

(In reply to br1ghtch1p from comment #59)
> (In reply to sampingu02 from comment #58)
> > (In reply to br1ghtch1p from comment #57)
> > 
> > > However I still get the notification on resume that desktop effects are
> > > restarted and I just wonder if this is now a normal message to expect on
> > > resume from suspend. For now I have muted out this notification.
> > 
> > Yeah I get that too every time I resume my computer from suspend. Is this
> > normal behavior?
> 
> That's exactly my same question. I don't think the 440 driver had this issue
> but my intuition tells me this is probably the new normal for the current
> fix. At least now kwin doesn't crash on resume.

I have this with the 440.100 driver and remember having had this for at least a year or so (i.e. with previous versions also). Haven't tried 455.28 yet.

(In reply to Fonic from comment #60)
> (In reply to br1ghtch1p from comment #59)
> > (In reply to sampingu02 from comment #58)
> > > (In reply to br1ghtch1p from comment #57)
> > > 
> > > > However I still get the notification on resume that desktop effects are
> > > > restarted and I just wonder if this is now a normal message to expect on
> > > > resume from suspend. For now I have muted out this notification.
> > > 
> > > Yeah I get that too every time I resume my computer from suspend. Is this
> > > normal behavior?
> > 
> > That's exactly my same question. I don't think the 440 driver had this issue
> > but my intuition tells me this is probably the new normal for the current
> > fix. At least now kwin doesn't crash on resume.
> 
> I have this with the 440.100 driver and remember having had this for at
> least a year or so (i.e. with previous versions also). Haven't tried 455.28
> yet.

I probably just didn't notice it with the 440 driver or my notification for such things were disabled. Anyway thanks to the Devs for taking time to provide a fix.

I guess these bugs must be fixed in 455.28 version. 

But how to update to them? When I run 'sudo apt install nvidia-driver-455', I get the message that the last version is already installed ('455.23.04').

I've only seen a new version driver available for download as a .run file on the NVIDIA website.  But why it's still not there in ubuntu repos?

(In reply to Max from comment #62)
> I guess these bugs must be fixed in 455.28 version. 
> 
> But how to update to them? When I run 'sudo apt install nvidia-driver-455',
> I get the message that the last version is already installed ('455.23.04').
> 
> I've only seen a new version driver available for download as a .run file on
> the NVIDIA website.  But why it's still not there in ubuntu repos?

Are you in Ubuntu? That is probably Ubuntu's latest driver. You might want to see Ubuntu's Testing/Extra repo if it's there.

(In reply to br1ghtch1p from comment #63)
> (In reply to Max from comment #62)
> > I guess these bugs must be fixed in 455.28 version. 
> > 
> > But how to update to them? When I run 'sudo apt install nvidia-driver-455',
> > I get the message that the last version is already installed ('455.23.04').
> > 
> > I've only seen a new version driver available for download as a .run file on
> > the NVIDIA website.  But why it's still not there in ubuntu repos?
> 
> Are you in Ubuntu? That is probably Ubuntu's latest driver. You might want
> to see Ubuntu's Testing/Extra repo if it's there.
I've tried to look for it on Google, but only found the main repo, which is 'ppa:graphics-drivers/ppa'. 
I've also seen the newer 455.28 version there, but it seems to be available only in 20.10 repos...
https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-455/455.28-0ubuntu1

I can confirm it is integrated in Ubuntu 20.10.

If you don't want to wait, what you could do is to add this ppa, and configure it to get "groovy" files instead of "focal", then download the driver, then revert the repository configuration back to focal.
But I'm not sure it's safe for your system.

(In reply to Lapineige from comment #65)
> I can confirm it is integrated in Ubuntu 20.10.
> 
> If you don't want to wait, what you could do is to add this ppa, and
> configure it to get "groovy" files instead of "focal", then download the
> driver, then revert the repository configuration back to focal.
> But I'm not sure it's safe for your system.

Yeah, I'm not sure either :D
Found a workaround, which is to switch effects rendering to \software' method - seems as the only way to go for now

I still seem to be having this problem on Kubuntu 20.10 running the 455.28 driver. After resuming from suspend Kwin has crashed and the sidebar in Systemsettings is black. Logging out and back in doesn't fix it. I have to do a full reboot. I've also noticed that even without suspending the system, Kwin crashes on login after logging out. The Systemsettings sidebar is black and everything seems slow to respond. I have a GTX 2070 Super.

(In reply to Erik Kurzinger from comment #50)
> To update, there *was* a driver regression which seems to be responsible for
> the symptoms described here. See
> https://bugs.kde.org/show_bug.cgi?id=424592#c11 for a description of the
> issue.
> 
> Unfortunately, I missed the deadline to get the fix into the 450.80 release
> yesterday. My apologies. However, it will be in the first official 455
> release, which I believe is scheduled for Oct. 7. I've also back-ported it
> to the 450 branch, so it'll be in the *next* 450.xx release as well.

Hello. Any expected timeframe for the next 450 branch update?
I cannot use 455 branch because of a null dereference regression that did not exist in 450 branch.
Thank you.

I'm using 455.38 (on Kubuntu 20.10), and while most issues experienced after suspend and resume seem to be gone, I still have severe rendering issues on a regular basis: first of all, Compositor settings have the same black screen effect described here, only after resuming from suspend or after a compositor crash.
And those compositor freeze and/or crash (compositor disabled, full back to Xrender often needed to reactivate it) happens frequently, with no apparent trigger, and the freeze can be 10s long… (also, it varies but most of the time it's a complete screen freeze for a few seconds, then I ear music again, then again freeze, then compositor crash and/or kwin restarts).

I'm reopening as it seems linked, but maybe it's another issue ?

I think I'm experiencing something similar. With compositing enabled, either I get horrible artifacting/blurring, or it'll just crash and disable the compositor. I'm running an RTX 3090, and I thought it was my motherboard because the RGB lighting on the motherboard stopped working the other day. So my brand new replacement (as in brand-new, not an RMA) motherboard came in today, I rebuilt, and I'm experiencing the same issues in both Arch and Manjaro. The only difference is that I can actually run some games so far, before with the other motherboard games wouldn't even launch anymore. I have an RMA approved with EVGA to get a replacement card, but after seeing this I'm not sure if there's anything even wrong with the card.