Bug 424311 - Severe Rendering Issues on Latest Nvidia Driver (450.57) (Arch)
Summary: Severe Rendering Issues on Latest Nvidia Driver (450.57) (Arch)
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 5.20.2
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 424681 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-16 22:27 UTC by Arix
Modified: 2024-06-07 16:57 UTC (History)
29 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot of compositor working under same Nvidia graphics driver, whereas before reboot it did not work. (997.86 KB, image/png)
2020-07-30 16:52 UTC, Bryson
Details
0001-Use-glXGetProcAddress-for-context-creation.patch (1.43 KB, patch)
2020-08-12 09:58 UTC, Fabian Vogt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arix 2020-07-16 22:27:59 UTC
SUMMARY
I have the original (2017) Gigabyte Aero 15X with a GTX 1070 Max-Q. I recently updated my Nvidia drivers from 440.100 to 450.57. After some small issues with the drivers not installing to the correct Kernel, the new Nvidia drivers seem to work fine now. I can load into SDDM and i3 just fine, with the Nvidia module loaded and active and all other applications are using the dedicated GPU just fine, so I am certain now that this is not a driver/module issue. However, kwin is completely broken. 

Loading Plasma causes severe compositing issues. I got a gray screen with different shades of gray where windows/task manager were open. Keyboard shortcuts still opened new windows, and their titlebars were visible and draggable, but contents were entirely gray. Resizing a window might flicker its contents, but it's unusable. I was at least able to get a usable desktop by changing the KWIN_COMPOSE environment variable. O2 or not set causes the above behaviour. KWIN_COMPOSE=X or O2ES produce a mostly normal display, but there are several compositing issues. Image artifiacts are left on screen, such as when opening and closing the Application Launcher, or resizing windows. Transparency also no longer works in applications that supported it before, though this could be a different issue, as dragging windows are still transparent. KWIN_COMPOSE=N to disable the compositor entirely works fine, but of course, there are no compositing effects.

I should note in case it wasn't implied, I didn't have any of these issues when using the 440 Nvidia driver, and I've tested several other applications with this 450 driver and they appear to work fine, including those that use OpenGL, or picom on i3. This is also not a problem when using integrated Intel graphics with software rendering.

STEPS TO REPRODUCE
1. Upgrade to the Nvidia 450.57 driver
2. Launch kwin/plasma with default settings

OBSERVED RESULT
Plasma is unusable, mostly gray screen except for titlebars.

EXPECTED RESULT
Compositing works normally.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux, Kernel Ver. 5.7.8.arch1-1
KDE Plasma Version: 5.19.3-1
KDE Frameworks Version: 5.72.0-1
Qt Version: 5.15.0-4

ADDITIONAL INFORMATION

KWin Support Information:
https://pastebin.com/GbMXunS5
Comment 1 David Edmundson 2020-07-16 23:07:24 UTC
Does it affect a clean new user session?
Comment 2 Arix 2020-07-16 23:21:22 UTC
(In reply to David Edmundson from comment #1)
> Does it affect a clean new user session?

Yep, same behaviour.
Comment 3 Arix 2020-07-26 05:49:27 UTC
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.
Comment 4 Vlad Zahorodnii 2020-07-30 07:47:55 UTC
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.
Comment 5 Nate Graham 2020-07-30 13:04:34 UTC
*** Bug 424592 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2020-07-30 13:05:27 UTC
*** Bug 424681 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2020-07-30 13:05:58 UTC
There's some fairly detailed information in duped Bug 424311.
Comment 8 br1ghtch1p 2020-07-30 13:29:37 UTC
@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.
Comment 9 br1ghtch1p 2020-07-30 13:38:43 UTC
(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.
Comment 10 Bryson 2020-07-30 16:44:55 UTC
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 :(.
Comment 11 Christoph Feck 2020-07-30 16:50:38 UTC
(resetting status)
Comment 12 Bryson 2020-07-30 16:52:26 UTC
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.
Comment 13 Bryson 2020-07-30 17:17:11 UTC
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.
Comment 14 Arix 2020-07-30 17:59:53 UTC
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
Comment 15 Bryson 2020-07-30 21:04:36 UTC
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.
Comment 16 Arix 2020-08-07 22:06:05 UTC
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.
Comment 17 br1ghtch1p 2020-08-08 17:59:10 UTC
@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.
Comment 18 Arix 2020-08-08 19:18:09 UTC
(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.
Comment 19 br1ghtch1p 2020-08-11 16:58:43 UTC
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.
Comment 20 Fabian Vogt 2020-08-12 09:58:57 UTC
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.
Comment 21 Fabian Vogt 2020-08-12 10:06:08 UTC
Setting needsinfo.
Comment 22 Fonic 2020-08-15 21:42:47 UTC
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
Comment 23 Fabian Vogt 2020-08-16 16:03:02 UTC
(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.
Comment 24 br1ghtch1p 2020-08-17 08:31:01 UTC
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.
Comment 25 Fabian Vogt 2020-08-17 08:32:55 UTC
(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.
Comment 26 br1ghtch1p 2020-08-17 08:41:34 UTC
(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.
Comment 27 br1ghtch1p 2020-08-17 13:53:19 UTC
(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?
Comment 28 Pietro Pizzi 2020-08-19 06:19:56 UTC
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.
Comment 29 Christoph Feck 2020-08-19 08:34:57 UTC
The issue is still visible after applying the patch from comment 20; setting status.
Comment 30 Erik Kurzinger 2020-08-19 21:41:59 UTC
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.
Comment 31 Arix 2020-08-20 00:07:40 UTC
(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.
Comment 32 br1ghtch1p 2020-08-20 08:25:02 UTC
(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.
Comment 33 Fonic 2020-08-22 09:16:10 UTC
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.
Comment 34 br1ghtch1p 2020-08-22 12:50:52 UTC
I can also confirm the update to 450.66 doesn't have an effect on the problem. Kwin still crashes on resume from suspend.
Comment 35 Fonic 2020-08-22 14:49:16 UTC
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
Comment 36 evilsourcerer 2020-09-16 15:07:10 UTC
Today, I updated packages again and now logging in results in plasmashell experiencing a segfault.
Comment 37 br1ghtch1p 2020-09-16 15:15:16 UTC
(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?
Comment 38 evilsourcerer 2020-09-16 15:47:21 UTC
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.
Comment 39 Lapineige 2020-09-19 07:17:54 UTC
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.
Comment 40 br1ghtch1p 2020-09-19 07:26:11 UTC
(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.
Comment 41 Fonic 2020-09-19 07:48:09 UTC
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).
Comment 42 br1ghtch1p 2020-09-19 11:46:39 UTC
(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.
Comment 43 Lapineige 2020-09-19 18:18:59 UTC
(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.
Comment 44 Fonic 2020-09-20 08:38:53 UTC
(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.
Comment 45 br1ghtch1p 2020-09-20 21:36:14 UTC
(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.
Comment 46 huyizheng 2020-09-21 05:28:54 UTC
Update to NVIDIA driver 455.23.04, it seems that the compositor will no longer crash, however, the issue screenlocker and systemsettings still occurs.
Comment 47 Lapineige 2020-09-21 06:24:42 UTC
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.
Comment 48 br1ghtch1p 2020-09-21 07:44:26 UTC
(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.
Comment 49 Lapineige 2020-09-21 17:21:48 UTC
(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.
Comment 50 Erik Kurzinger 2020-10-01 16:48:08 UTC
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.
Comment 51 br1ghtch1p 2020-10-02 21:53:02 UTC
(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?
Comment 52 Erik Kurzinger 2020-10-02 22:52:07 UTC
(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.
Comment 53 Samuel 2020-10-08 13:50:07 UTC
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 :)
Comment 54 Nate Graham 2020-10-08 13:50:50 UTC
Phew!
Comment 55 jbmw16 2020-10-09 02:44:38 UTC
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.
Comment 56 jbmw16 2020-10-09 02:46:12 UTC
My mistake, seems .28 is still not yet rolled out, ill wait
Comment 57 br1ghtch1p 2020-10-09 06:42:53 UTC
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.
Comment 58 Samuel 2020-10-09 07:19:33 UTC
(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?
Comment 59 br1ghtch1p 2020-10-09 08:47:27 UTC
(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.
Comment 60 Fonic 2020-10-09 08:50:20 UTC
(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.
Comment 61 br1ghtch1p 2020-10-09 08:56:31 UTC
(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.
Comment 62 Max 2020-10-16 06:34:22 UTC
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?
Comment 63 br1ghtch1p 2020-10-16 07:48:48 UTC
(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.
Comment 64 Max 2020-10-16 19:34:37 UTC
(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
Comment 65 Lapineige 2020-10-16 19:38:52 UTC
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.
Comment 66 Max 2020-10-16 19:43:07 UTC
(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
Comment 67 Nick 2020-11-05 03:52:46 UTC
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.
Comment 68 Hussam Al-Tayeb 2020-11-18 14:49:27 UTC
(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.
Comment 69 Lapineige 2020-11-21 17:25:32 UTC
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 ?
Comment 70 Matt M (gardotd426) 2021-01-16 01:20:46 UTC
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.
Comment 71 Zamundaaa 2024-06-07 16:57:12 UTC
This bug report is about a driver bug that was fixed a very long time ago, so I'm closing this