Bug 344326

The contents of the index buffer are probably not preserved when the system is suspended.
A possible reason for the intermittent reproducibility is that it takes a while for the charge in VRAM to decay.

This is the same bug as #343433.

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

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

This bug only happens when the magic lamp effect is enabled and the bug can be consistently reproduced on resume by minimizing/maximizing windows prior to sleep/suspend.  See bug 323686 which has been marked as a duplicate of this bug.

I had Magic Lamp effect disabled all this time, but still the bug appeared. Maybe bug 323686 is somewhat different.

I'm with Ruslan. I didn't have the Magic Lamb enabled and yet I get the bug.

Then, based on Ruslan's and Alexander's comments, bug 323686 should NOT be marked as a duplicate of this bug. Thomas Lübking needs to un mark bug 323686 as a duplicate of this bug.

I doubt the magic lamp thing has a direct impact on this - rather it might raise odds to run into this.
Bear in mind that the suggested cause is a decay in the memory banks that corrupts the index buffers (and the quad count will rise quite some for the ML effect)

@Fredrik
Could this be dut to GLPlatform::preferBufferSubData() ?

Anyone here opting-in to compile a testing patch in that direction?

I'll try to test any patches, but testing can again take several days to make sure the bug isn't just hiding.

BTW, Magic Lamp effect indeed boosts reproducibility of this bug. I just have to do several minimize/unminimize actions before suspend, and most likely the corruption will reproduce on resume.

Patch (for testing buffer subdata copying rather than buffer range mapping being the culprit) is trivial:

diff --git a/libkwineffects/kwinglplatform.cpp b/libkwineffects/kwinglplatform.cpp
index 548d459..50f0ba2 100644
--- a/libkwineffects/kwinglplatform.cpp
+++ b/libkwineffects/kwinglplatform.cpp
@@ -784,7 +784,7 @@ void GLPlatform::detect(OpenGLPlatformInterface platformInterface)
 
         if (m_driver == Driver_NVidia) {
             m_looseBinding = true;
-            m_preferBufferSubData = true;
+//             m_preferBufferSubData = true;
         }
 
         if (m_chipClass < NV40) {

(In reply to Thomas Lübking from comment #9)
> @Fredrik
> Could this be dut to GLPlatform::preferBufferSubData() ?

The commit that adds preferBufferSubData() is not the commit Ruslan bisected the problem to, so no.

(In reply to Thomas Lübking from comment #12)
> Patch (for testing buffer subdata copying rather than buffer range mapping
> being the culprit) is trivial:
Doesn't change anything, the bug still reproduces.

Today I've discovered that this is also triggered by screen configuration change. Namely, I have a TwinView setup, and when I tried to move two displays onto each other and clicked "Apply" in nvidia-settings, I got the same type of corruption. This corruption also occurs not every time, and enabling Magic Lamp effect helps to reproduce this too.

The Magic Lamp effect will reproduce it every time if you minimize/maximize a window just prior to suspend.

This bug affects me too.

I'm using nvidia prop driver. When hibernate or suspend, the screen is corrupted on resume.
I got just the same triangle flickering pattern. However, I can trigger the problem with small suspends (seconds).

The workaround disabling and enabling compositing always works.

02:00.0 VGA compatible controller: NVIDIA Corporation GF108GL [Quadro 600] (rev a1)
OpenGL version string: 4.4.0 NVIDIA 340.76

I guess this bug can be marked as confirmed.

Because of recent comment on bug #323686
Anyone here who is NOT running an optimus (ie. intel+nvidia) system?

I am NOT running optimus.  I am running an NVIDIA Corporation G92GLM [Quadro FX 3600M] (rev a2) video card and version 340.76 of the nvidia G03 driver from the OpenSUSE nvidia repo.

I guess NO ONE here runs an Optimus system because with such a system, nVidia is dormant.
On my desktop system with nVidia, I've experienced this bug for several months but, on my new Optimus system (laptop), I don't see it anymore because Intel is the active card.

Ok, just thought because you presented the output of "optirun glxinfo" and thought that *might* mean something.
You btw. are using indexed quads on the intel system, so it's not the problematic path would just be avoided there. There's apparently a different behavior on the driver/HW level.

I'm also not on optimus

I'm probably stating the obvious here, but if the problem is corruption of the index buffer, the solution is to recreate it on resume.

But "on resume" must then also mean on screen reconfiguration via xrandr and switch to VT and back to X. Does this look like a problem in the driver instead of kwin?

I mean these are separate scenarios:
1) Reconfiguration via xrandr
2) VT switch to terminal and back to X

Leaving aside that to hook on a resume we've to rely on
- powerdevil being up and/or (in near future)
- login1 (because upower will/has drop/ed this signal to systemd) or 
- write and readback timestamps (and check for a gap...)

At least I'm not aware of (ideally POSIX) userspace events for this condition.

(In reply to Ruslan Kabatsayev from comment #24)
> But "on resume" must then also mean on screen reconfiguration via xrandr and
> switch to VT and back to X. Does this look like a problem in the driver
> instead of kwin?

Right, it would have to be done in all those cases.

An OpenGL implementation is not allowed to spontaneously lose the contents of buffers and textures, so this is a problem with the kernel, the driver, or the hardware. The exception is EGL, where eglSwapBuffers() is allowed to return false and generate EGL_CONTEXT_LOST at any time.

But keep in mind that we still haven't confirmed that the problem really is that index buffer is lost.

Thomas Lübking from comment #26)
> Leaving aside that to hook on a resume we've to rely on
> - powerdevil being up and/or (in near future)
> - login1 (because upower will/has drop/ed this signal to systemd) or 
> - write and readback timestamps (and check for a gap...)
> 
> At least I'm not aware of (ideally POSIX) userspace events for this
> condition.

Solid abstracts this away (Solid::Power::resumeFromSuspend), so kwin doesn't need to concern itself with the mechanism.

How can we help debug the problem?
Bt full?
Coredump?
I know nothing about opengl prog or kwin internals. How could one detect that it is really index corruption?

Restarting compositing on system resume is a workaround but it is no bug fix.

"Interestingly" I gest some screen corruption w/ changing the amout of screens on KF5.

I wonder whether it's the same issue and, depending on the HW/setup, the wake from STR implies a screen (size) change as well.

This patch "mostly"* resolves it.


diff --git a/scene_opengl.cpp b/scene_opengl.cpp
index 7584dd5..de7b7a9 100644
--- a/scene_opengl.cpp
+++ b/scene_opengl.cpp
@@ -839,7 +839,9 @@ void SceneOpenGL::screenGeometryChanged(const QSize &size)
     m_backend->screenGeometryChanged(size);
     ShaderManager::setVirtualScreenSize(size);
     GLRenderTarget::setVirtualScreenSize(size);
-    GLVertexBuffer::setVirtualScreenSize(size);
+    GLVertexBuffer::cleanup();
+    GLVertexBuffer::initStatic();
+//     GLVertexBuffer::setVirtualScreenSize(size);
     ShaderManager::instance()->resetAllShaders();
 }

* The change takes quite long. During that time the screen is black + mouse cursor but after a few seconds (~10?) I get a normal desktop.

Hi, just updated to frameworks 5.2.1 under arch linux this afternoon... it hasn't done it had the problem so far after un-hibernate, and my laptop was off for a good 5 hours. Will keep an eye on it though.

That being said, I did experience the problem when plugging new monitors in sometimes, not just when restoring from hibernate/sleep.

ie the laptop was up and running with its built in screen fine, but just plugging in my additional two monitors at work caused the triangle corruption.

Note: I experienced the problem with two additional monitors prior to the 5.2.1 upgrade. I'll see if it still glitches at work tomorrow morning.

Ah, just managed to trigger it by unplugging and replugging my external monitor a few times (slowly, letting it recover from each change). So I don't think its likely the post-hibernation memory decay issue hypothesized above.

However, I would like to confirm that disabling/re-enabling compositing does indeed fix it here as well. My problem previously was that you can't toggle compositing from the lockscreen, which is what I had enabled post-dehibernation.

I'm using a Quadro K3000M NOT using Optimus BTW if that helps.

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

Jfi, I can only reproduce that with Plasma5, not with KDE4.

I am running Linux Mint 17.1 with 4GB of Ram
Kernel 3.16.0-25-generic
Nvidia propietary driver 340.24
KDE 4.14.2 
Every time I suspend to Ram or Sleep my laptop, when it wake up I only see the mouse with a black background so I have to press Ctrl + Alt + Backspace to restart xorg to keep working, this is very annoying, I try different kernel versions, different Nvidia propietary versions and nothing worked so I install LXDE and it does not have any problems waking up so at the end I found that:

If you activate any effect that that take place on Window open, close, minimize or maximize like: 
Fade, Fall Apart, Glide, Magic Lamp

Will cause the bug to appear but if you turn them off wake works correctly.

Also happens when you plug or unplug a secondary monitor.

When it wake up shows a blank screen but if you move the mouse to the upper left corner shows part of the screen before sleep (see picture attached), the mouse moves around but nothing else works until you reset xorg by pressing Ctrl + Alt + Backspace.

Created attachment 92705 [details]
Blank screen after wake up

Notice that if SHIFT+Alt+F12 doesn't work, it's a different issue (kernel or X11 level)

I do not know what Shift+Alt+F12 is supposed to do but in my case does nothing and if I press Ctrl+Alt+F1,F2,F3,F4,F5,F6,F7,F9,F10,F11,F12  I get a blank screen No console, but if I press Ctrl+Alt+F8 I get GUI.

But if is a Kernel problem how come it did not work well with Ver 3.13.0-37 or newer kernels?

It used to work fine before but after some updates the problem appear.

I also try turning compisiting off following this site recommendations: https://devtalk.nvidia.com/default/topic/581510/black-screen-on-resume-from-suspend-with-325-15-and-kwin-4-11-with-enabled-compositing/ 

Before suspend to ram with all effects activated and system resume but screen flicker a lot after waking up.

(In reply to Alonso Murillo from comment #38)
> I do not know what Shift+Alt+F12 is supposed to do
Suspend resp. resume the compositor (the thing that makes windows transparent, paints shadows and stuff)

> but in my case does nothing
Neither before the issue occurs?
If it's inoperative only *while* the screen is black after resuming from STR, kwin *might* be deadlocked (eg. in glSwapBuffers) - since you apparently cannot get access to a linux VT in this case: can you inspect the system from another machine (via ssh)?

> and if I press Ctrl+Alt+F1,F2,F3,F4,F5,F6,F7,F9,F10,F11,F12  I get a
> blank screen No console, but if I press Ctrl+Alt+F8 I get GUI.
Before/without causing the issue, please call

   dmesg | grep NVRM

If this yells a warning about not using a VGA console:

[ 2.795733] NVRM: Your system is not currently configured to drive a VGA console
[ 2.795735] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
[ 2.795736] NVRM: requires the use of a text-mode VGA console. Use of other console
[ 2.795737] NVRM: drivers including, but not limited to, vesafb, may result in

see eg. https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer on how to fix that.

Thank you Thomas for your quick replies, I tested:
dmesg | grep NVRM

And I got: 
[   29.972648] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.24  Wed Jul  2 14:24:20 PDT 2014

So every thing seems good I think, I also try uncommenting 
GRUB_TERMINAL=console

In /etc/default/grub  But did not worked.

No framebuffer console seems to be used, so that's fine.

Please clarify the ability to suspend the compositor before (in an operative environment) and after the resume from STR.
If suspending the compositor (in doubt try "qdbus org.kde.KWin /Compositor suspend") even before going STR results in a black locked screen, you're apparently at the screen locker (which is black "internally" or fails to show the greeter)

Either disable screen locking for STR or suspend the system directly:

   qdbus --system org.freedesktop.login1 /org/freedesktop/login1 Suspend false

and see whether that causes you an "dead" screen on resume as well.

Thanks Thomas, I tested as you suggested:

qdbus org.kde.KWin /Compositor suspend
qdbus --system org.freedesktop.login1 /org/freedesktop/login1 Suspend false

And it does suspend to Ram and wake up correctly, I also try:
qdbus org.kde.KWin /Compositor suspend

Then K, Leave, Sleep; and also works correctly as long as compositor (Effects) are disabled.

Do you usually wake up with the screen locked? (eg. when trying w/ the suspended compositor)

No Thomas Lock on resume is disabled, I already try that, I switch to Linux about 7 years ago, I got tired of Windows getting corrupted for no reason.

I am a programmer Assembly, C++, PHP, CSS, Access, Mysql I do not know exactly what is causing the problem but all this effects: Fade, Fall Apart, Glide, Magic Lamp should have some thing in common they should be doing some thing at wrong time (before video wake up is completed) and that is causing screen corruption.

No Thomas Lock on resume is disabled, I already try that, I switch to Linux about 7 years ago, I got tired of Windows getting corrupted for no reason.

I am a programmer Assembly, C++, PHP, CSS, Access, Mysql I do not know exactly what is causing the problem but all this effects: Fade, Fall Apart, Glide, Magic Lamp should have some thing in common they should be doing some thing at wrong time (before video wake up is completed) and that is causing screen corruption.

The mentioned effects "do" nothing most of the time and if the kernel isn't ready when kwin makes some opengl calls, it's expected to schedule them until it wants to execute them (that's what OpenGL does all the time anyway)

What these effects (except fade, I'm not sure whether it's really related - first time i hear it's a supporter) however do once invoked is to (vastly) increase the quad amount, thus index buffers (and the likelyhood to run into currupt VRAM)

See the very first comments in this regard.

The only thing that worried/worries me about your report was that you stated *only* killing X11 would do and that does completely not match this bugreport, where everyone else could clear the stage by simply suspending (and restarting) the compositor, thus rebuild the index buffers.

If that doesn't work and the reason is not that the compositor shortcut is blocked by the screen locker, you're experiencing a differen bug, likely on a lower level (X11 - or kernel, given you claimed the VTs (ctrl+alt+F<x>) would be affected as well. It my still be triggered by the presence of one or more GL contexts when suspending the system)

This is a very crude hack, but, for now, *seems* to work (eg. also when switching VTs)

Testers welcome!

PLEASE NOTICE!!!!!!
--------------------------
The patch is a bit glitchy, it binds a lambda on a 500ms timer w/o a guarding object.
Ultimately it should be  a member of SceneOpenGL, but i wanted the patch low profile ;-)

------------

diff --git a/scene_opengl.cpp b/scene_opengl.cpp
index c33f5cc..3004158 100644
--- a/scene_opengl.cpp
+++ b/scene_opengl.cpp
@@ -448,6 +448,17 @@ SceneOpenGL::~SceneOpenGL()
     }
 }
 
+static void scheduleVboReInit()
+{
+    static QTimer *timer = nullptr;
+    if (!timer) {
+        timer = new QTimer;
+        timer->setSingleShot(true);
+        QObject::connect(timer, &QTimer::timeout, []() { GLVertexBuffer::cleanup(); GLVertexBuffer::initStatic(); });
+    }
+    timer->start(500);
+}
+
 void SceneOpenGL::initDebugOutput()
 {
     const bool have_KHR_debug = hasGLExtension(QByteArrayLiteral("GL_KHR_debug"));
@@ -469,10 +480,12 @@ void SceneOpenGL::initDebugOutput()
             qCWarning(KWIN_CORE, "%#x: %.*s", id, length, message);
             break;
 
+        case GL_DEBUG_TYPE_OTHER:
+            if (strstr(message, "Buffer detailed info:") && strstr(message, "has been updated"))
+                scheduleVboReInit();
         case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR:
         case GL_DEBUG_TYPE_PORTABILITY:
         case GL_DEBUG_TYPE_PERFORMANCE:
-        case GL_DEBUG_TYPE_OTHER:
         default:
             qCDebug(KWIN_CORE, "%#x: %.*s", id, length, message);
             break;

What version of kde-workspace should i have for the patch to apply? I've tried on 4.11.14, but it failed to apply.

Oh, sorry.
The patch is for KWin 5.3/5.4
The error/debug handling code I hooked into doesn't even exist in KWin 4.x (and the patch uses c++11 and Qt5 features, so it won't compile), so this won't be easy to backport :-(

review request for the workaround.

This bug affected me in KDE 4 and it still affects me in KDE 5. Here is some info:

1. This happens after waking from sleep (almost every time) or switching from a TTY (rarely).
2. I am running NVIDIA proprietary drivers. This happens regardless of the version of the driver. I do not have Optimus. None of the options in nvidia-settings help.
3. No other compositor does this.

I work around this issue by logging in blindly and running "kwin_x11 --replace".

Git commit 9f13e9b26035984906896a56d64e85e11522c581 by Thomas Lübking.
Committed on 03/06/2015 at 19:38.
Pushed by luebking into branch 'master'.

WORKAROUND for nvidia VBO failures

When switching virtual terminals,
suspending to ram and resizing the
screen (GL viewport) at least the
nvidia driver moves VBO data between
the video RAM and the system heap -
and something about this isn't reliable:

An often perceived resulted are scattered
windows but it may also be the cause for
entirely black screens reported for same
occasions.

As a workaround, we hook into the GL debug
messages and filter them for the suspicious
message, then re-init VBOs

TODO:
figure whether that's our fault or nvidias

REVIEW: 123936

Patch applies to KWin 5.4

M  +30   -1    scene_opengl.cpp

http://commits.kde.org/kwin/9f13e9b26035984906896a56d64e85e11522c581

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

Hello reporting my bug with the dual monitors going blank or the display going crazy coming out of "overnight" sleep mode seems to have been fixed with the latest updates on Kubuntu.

The interesting questions would be
- what got updated (nvidia? kwin?)
- in case kwin got updated: did kubuntu backport the patch?

I always had rendering problem and combing effects using the default Nouveau driver. This time I actually switched back from Nvidia to Nouveau driver and was still experiencing the same issues with the monitors. In my case, I would eliminate an issue with Nvidia.

I don't know exactly what got updated, but I did see some kde and qt4, qt5 libs scroll past the screen. Also previously before I "upgraded" my kubuntu system from 14.10 to 15.04, I had video coming problem (messy scan lines), I had to actually switch from using Nouveau driver to Nvidia to fix the problem. Give my person experience, I would have suspected the problem is with the Nouveau driver/code.

At this moment I am still using the Nouveau display driver and the monitor bug is gone. Wish I would help you with more detail that but as much as I know. Unless there is a way for me to poke around to obtain install lib information.

It's not particularily surprising that you don't get this bug with the nouveau driver.
It gets interesting with the nvidia blob (and the recent patch)

Created attachment 93155 [details]
Effective reversal of the first bad commit to work around the problem in KDE4

For those who are still on KDE4, but want pre-regression experience, here's a patch which effectively reverses the commit which made it possible to use indexed quads instead of triangles.
I admit that kwin devs might be unhappy about it, and it's not intended to be merged upstream, but I think there'll be some users who'll find it useful.
The patch is done against kde-workspace-4.11.14, and it prevents screen blackening/corruption on resume for me.

I just got a new graphics card (a GTX 960) and this still happens.

Also, last time I forgot to mention that this sometimes happens when I switch to a TTY and back.

Oh, and I have two monitors with different refresh rates and screen resolutions, one connected via DVI-D and the other via DVI-I to VGA adapter. Could this have anything to do with this?

(In reply to Nick Guletskii from comment #60)
> I just got a new graphics card (a GTX 960) and this still happens.

It's at best worked around in 5.4 - since 5.4 is not released (until August), you're either using kwin from git master or can expect to run into this.

I opened a similar (not the same "manual" workaround) in this thread:
https://bugs.kde.org/show_bug.cgi?id=349210

Since yesterday, I have suspended and resumed 4-5 times without the issue occurring, while previously I have had a 100% success rate at reproducing the bug.

Did I just get lucky?

- Distro: Arch Linux
- Kernel: 4.0.7-2
- Display driver: Nvidia 352.21-2
- GPU: 560 Ti
- Kwin: 5.3.2

Uncertain - at least the workaround is not in this version (unless ubuntu applied it downstream)
Did you update kernel or nvidia blob?
Notice, that I almost *never* encountered this by wake up from STR, recently a perfect way to reproduce it (before the workaround) was to alter the screen layout/resolution or switch the VT.

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

I just managed to track down this issue and skimmed through the comments.

Any progress on this? It`s a really annoying problem that is nagging me for quite a long time now.

Thanks for your work so far!

----------
KWin version: 5.3.2
OpenGL renderer string: GeForce GTX 560M/PCIe/SSE2
Driver: NVIDIA
Driver version: 352.41
Linux kernel version: 4.1.6 (4.1.6-200.fc22.x86_64 @ Fedora 22)

Have this issue on Fedora 21, kwin 4.11.18.

There won't be an upstream workaround for KWin/4 anymore (kde-workspace is frozen)

You'll have to ask your distro to add the required bits (gl debug message handling and VBO resets) - or for nvidia to really fix this. Sorry.

I can confirm this issue is solved with plasma / KWin 5.4.1 (possibly already in 5.4.0?). After resuming from suspend or adding/removing external displays, the screen corruption/deformation is visible for a tiny fraction of a second, before the screen resets itself into a normal state.

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

Running Kubuntu 15.10 (Plasma 5.4.2) and experiencing a random segfault upon wake from suspend. Can restart Plasma (ctrl-alt-backspace) but other times I need to re-boot from shell (ctrl-alt-F1).  System: Asus Z87-PRO,  i7-4770K @ 3.5 GHz (no OC),  16 GB RAM. Using 3 displays with an Asus GTX-750 Ti GPU and latest Nvidia drivers. Would love to fix this.

a) why do you kill the X server if some client segfaults? esp. kwin and plasmashell autorestart on segfaults. and worse: why do you need to reboot? (in that case the kernel would have been messed up - maybe related, but totally out of scope)
b) this is very most likely a memory corruption when the nvidia driver transfers data between system and video RAM. if it notices an error, we can work around that by dropping all data (happens in 5.5), but we can no way work around segfaults, sorry.

from you description, i'm not sure that you encounter this bug, but rather run the nvidia driver on a framebuffer console, see https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer

Plasma does not always restart. Sometimes I can save with one method other times one or more screens are black and the only graceful thing I've thought to do is reboot via CLI or (lately) try restarting plasma so as not to reboot. Yes, sometimes, I see a message and plasma restarts automatically. Eventually, however the situation will arise where the displays are useless. Thanks for responding. I'm a new Linux convert, so keep that in mind. Been less than a year.

(In reply to Woods Wannamaker from comment #73)
> Plasma does not always restart.
There is no "Plasma" (itr ;-)

There's "kwin" (or "kwin_x11") and "plasma-desktop" (or "plasmashell") processes.
Former is window manager and compositor, latter is your desktop and panels.
You'd need to check (ps ax) which one's still running.
A restart failure could occur because drkonqi stopped the process before it could free resources, see bug #353428

> Eventually, however the situation will arise where the displays are useless.
Check whether that's just the visual output (press SHIFT+Alt+F12 to suspend the compositor), but if it "survives" X11 restarts (ctrl+alt+backspace) it's a kernel problem, I'd bet on the framebuffer thing (check your config with "dmesg | grep NVRM", it will print a warning for a bad setup) I linked.

PS: just noticed a typo in my former post, the workaround for corrupted memory (*this* screen corruption) is actually in 5.*4*, so if you encounter broken visuals, it's unlikely *this* bug.

woods@kdepc:~$ ps ax|grep kwin
 2266 ?        Sl     4:25 kwin_x11 -session 10ce646570000144821732500000022470002_1448217728_679596
10604 pts/0    S+     0:00 grep --color=auto kwin
woods@kdepc:~$ ps ax|grep plasma-desktop
10608 pts/0    S+     0:00 grep --color=auto plasma-desktop
woods@kdepc:~$ ps ax|grep plasma
 6275 ?        Sl     0:32 /usr/bin/plasmashell -s --crashes 1
10610 pts/0    S+     0:00 grep --color=auto plasma
woods@kdepc:~$ dmesg|grep NVRM
[    3.028945] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  352.63  Sat Nov  7 21:25:42 PST 2015

I captured some info (a bit long) from the segfault that happened today and can post if that helps, but maybe the kernal message gives the story. I upgraded to 15.10 from 15.04 AND added the GTX-750 at the same time.

That says the original kwin_x11 process is running, plasmashell (wrong component, this is kwin bug) restarted at least to recover from a crash.
You're not running on a framebuffer console, so that should be no problem w/ the nvidia driver.

What info should I try to capture for debugging when the crash occurs? Would it already be in the kernlogs? I've captured info following one crash, but it's a lot to post here, even starting with the timestamp of the event.

If a KDE process crashes, you usually get a crash dialog (DrKonqi) which allows you to report the crash (including the backtrace in the "developer information" tab)
plasmashell crash reports do *not* belong into /this/ bug, please file a new one (against plasmashell)!

Other "crashes", notably issues in the kernel are not easy to debug. Esp. for the kernel you require a core dump and inspect that (since you cannot use the crashed system to inspect itself)
Crashes that are no segfaults but just some weird condition in the system require to first figure *where* that weirdness occurred.

Rule of thumb: any graphical issues caused by the compositor can be resolved by killing the kwin_x11 process. If the distorsion remains, the issue is in the X11 server (nvidia driver)

Usually, in Plasma, I only have a part of the windows with noise, as I told previously. But yesterday, after wake up, the screen was in  black and no way to recover a visible screen. Only the cursor was visible. I needed to do "<Ctrl><Atl><BackSpace><BackSpace>" to recover my desktop  :(

Another atypical issue I saw some time in the unlock screen is "crossed text", that's to say, the text  (and only the text) appeared  like if you put your eyes "crossed". I have some screenshot of this and will send here.

(In reply to Rafael from comment #79)

> way to recover a visible screen. Only the cursor was visible. I needed to do
> "<Ctrl><Atl><BackSpace><BackSpace>" to recover my desktop  :(

Do you lock the screen over STR?

(In reply to Rafael from comment #79)
> Another atypical issue I saw some time in the unlock screen is "crossed
> text", that's to say, the text  (and only the text) appeared  like if you
> put your eyes "crossed". I have some screenshot of this and will send here.

It might be bug 307003.

Thank you Ruslan Kabatsayev , but it's not the same issue.  Mine only had happened if login after wake up.  The 307003 bug seems to be subpixel rendering related.
; )

It's related to a shader based, hyperfast multisamplig (FXAA) which, ie enabled *while the GL context is created!*, turns the entire desktop blurry (but is indeed especially notable on text - or other thin lines with high contrast ;-)
You should better *not* have FXAA enabled in nvidia-settings (I script-toggle it around starting "legacy" GL games)

Try to get us the screenshot for a sentence on the cause.

Hi again. 

Thomas Lübking , I don't know what's the meaning of STR. If you ask me if I suspended my desktop PC on the locked screen, I should say "maybe", cause I have a delay of 1 hour to sleep my system when afk.

Created attachment 95835 [details]
"Doubled view" on one of my two monitors in the lock out screen

I have TWO monitors, and only the default monitor showed the "doubled" text in the screen lock.

Created attachment 95836 [details]
My second monitor (not the primary, but the VGA) was showing correctly the text.

Suspend To Ram ;-)

Can you interact with the login screen with the bricky text?
(Either the particular greeter GL context - *in* the client - has trouble with its glyph cache or the greeter isn't shown at all and you see a superimposition of various paints onto the root window)

I assume your problems are related to the lockscreen greeter. Can you disable screen locking (across STR) and see whether you still have problems?
(The greeter is written in QtQuick, which is an OpenGL scene and will likely suffer from the same issues KWin faced before the workaround)

Ok with STR.  I must say that I ONLY have "bricky text" on the screen lock form window. Just some hours ago I had a similar issue (see the next screenshot) but this time I even can only enter my password in one of my monitors, exactly the other one that have not that issue. Apparently, this problem always happen in my DVI monitor, not in the VGA monitor (if it can help someway). 

But disable screenlock will not do nothing about the "bricked text", cause it only appears on the screenlock window.

Created attachment 95851 [details]
Some letters are hidden. Below the time "martes, 1 de diciembre de 2015" and "Desbloquear" in the button.

Comment on attachment 95851 [details]
Some letters are hidden. Below the time "martes, 1 de diciembre de 2015" and "Desbloquear" in the button.

It should show: "martes, 1 de diciembre de 2015" below time. And "Desbloquear" in the button.

(In reply to Rafael from comment #88)

> But disable screenlock will not do nothing about the "bricked text", cause
> it only appears on the screenlock window.

That's ok. Basically, If you don't get the black/locked/inaccessible screen after STR anymore when locking is disabled (notice that aside the time trigger, powerdevil has a dedicated feature to lock the screen when STR! See power settings in system settings), we can be pretty sure that it's not the compositor or driver, but the problem is contained within the locker (and likely greeter, probably due to the GL issues we worked around in KWin)

The new screenshots are the old. Basically some glyph datas are corrupt, see eg https://bugreports.qt.io/browse/QTBUG-44279

reference bug 323686, comments 55, 58 etc.

The bug is still reproducible on Linux Mint 17.3 with nvidia 340.96, kwin 4.4.11, linux 3.13.0.24.

On Arch with nvidia 340.96, kwin/plasma 5.5.3, , linux 4.3.3, the bug is no longer reproducible.  

That is,  on Arch running 5.5 you can:

1. enable effects and  magic lamp. 
2. Minimize and restore a few windows
3. navigate to a tty VT 
4. navigate back to the graphics VT running kde  

and the screen will properly render. 

On Mint running 4.4 you still get the black screen with only the cursor drawn.

Yes, it's supposed to be work-a-rounded by the patch in comment #53 (applies to 5.4 and up)

Created attachment 97061 [details]
Disable KDE compositor uppon lock screen (and restore state after)

Using Linux Mint 17.3 KDE Edition, I'm affected by this 1 year old bug on this brand new distro installation :(
I not sure to be willing to patch and compile the whole KWin myself, next Mint is 6 months away with the right KWin version I hope...

My main concern was to be locked out by the screensaver with a crazy screen and not being able to type in the password and get back to the session for a alt-shift-F12 ...

So I took a few hours to make those python lines in attachment:

It stops compositing uppon screen lock (kde) and put it back as it was uppon unlock.

(I've just registered here to share this small script)

This bug is about resuming from STR (and nvidia), not about screen locking.
Also it's worked around in 5.4 (though kwin can still crash in the driver)

Thanks for keeping an eye on this bug.

What I have in common about the bug in description and comments 1-93 :
- "I see sometimes black, other times corrupted screen with blinking triangles of distorted windows content"
- "running 64 bit kernel"
- "nvidia video cards" "GeForce GTX" (mine is 970)
- "kwin with OpenGL compositing on an nvidia card with binary driver"
- "Magic Lamp effect indeed boosts reproducibility of this bug"
- "this is also triggered by screen configuration change" (I do xrandr to dim screen)
- "workaround disabling and enabling compositing always works"
- "disabling/re-enabling compositing does indeed fix it"
- ...

So I do have this very bug (even if I don't STR - suspend to RAM)

Also: Andrew de Quincey says (32) "My problem previously was that you can't toggle compositing from the lockscreen"
Me too.

I have Mint 17.3 with
Linux 3.19.0 x86_64, KDE : 4.14.2 , KWin : 4.11.11
NVidia Driver Version: 352.63

(BTW if my comment isn't relevant for some reason I'd be glad to know why and how I could make a quick fix before getting the next distrib release)

As mentioned, there's a workaround in KWin 5.4 and up.
4.x won't see any upstream updates and the patch isn't easy to backport.

The bug is (likely) in the nvidia driver when moving VBOs between system and video RAM. I have frankly not the least idea how or why that should happen when locking the screen (except when it's rather "when suspending the screen, causing a randr event, and the screenlocker is just randomly invoked as well")

I've found this talk mentioning a new nvidia driver that no longer has the suspend-to-RAM broken :
https://devtalk.nvidia.com/default/topic/791786/linux/dpms-not-working-on-gtx980-with-displayport-connection/3
It's mainly about DPMS not working but STR as well in comments page 3.
352.63 (2015.11.16) : bug (I have this one)
358.16 (2015.11.20) : fixed (but no mention in changelog)

I'll add a feedback here if I manage to get this version working for my distro:
This would mean that the workaround can be removed from the KWin code to keep it clean and tidy.

Bad news:
Driver Version 361.28 still has the bug with KWin : 4.11.11.
No more crazy triangles but X hang and STR  or simple system shutdown may hang.
I'll have to upgrade distro for next KWin...

Sure it's the same bug? Can you ping or even ssh into the woken (but black) machine or maybe even switch the VT? Does it go away when suspending the compositor before STR?
(Wake-up issues can have other causes, eg. the CPUs µ-code loader knocked me out for a while)

(In reply to Ruslan Kabatsayev from comment #0)
> Often after I suspend my machine, wait some time and resume back, I see
> sometimes black, other times corrupted screen with blinking triangles of
> distorted windows content. This happens on at least two machines I'm working
> on, both with nvidia video cards (one Quadro (can't tell details yet),
> another GeForce GTX 750 Ti with binary driver 340.46), both machines running
> 64 bit kernel.
> 
> This is a regression, and I've run git-bisect to find that the bad commit is
> commit 1f0bb6d36075b0b14c927b91d5c3df6720826afd
> Author: Fredrik Höglund <fredrik@kde.org>
> Date:   Thu Mar 21 23:52:03 2013 +0100
> 
>     kwin: Use the new API for rendering quads
> 
> This bug sometimes doesn't reproduce, so I can only be _almost_ sure that
> previous versions don't have it. But I've tested kwin version right before
> this commit, at f709af7c7e23010293c8eb9fa67871adfdb75207, and haven't seen
> any problems for several days, so I think the above bad commit should be the
> right one.
> 
> Reproducible: Sometimes
> 
> Steps to Reproduce:
> 1. Run kwin with OpenGL compositing on an nvidia card with binary driver
> 2. Suspend to RAM
> 3. Wait several minutes (sometimes needs hours, don't know what triggers it)
> 4. Resume
> 
> Actual Results:  
> Screen is garbled with flickering triangles textured with parts of desktop
> content, or sometimes screen is just black
> 
> Expected Results:  
> Desktop should render normally
> 
> Toggling compositing off and on by double pressing Alt+Shift+F12 fixes the
> screen and lets me work normally until next suspend/resume cycle.

The same thing also happens whenever I change resolutions. If I have a game start up in a lower res, and then change it, it also happens. I was wondering if you have multiple monitors. I have a laptop set up with an external monitor that I run with the lid closed. The machine always goes to  the laptop monitor (1920x1080) when KDE starts (gonna be researching this bug next). After entering the password (have to do it blind) it will change over to the external (1920x1200) monitor. I was thinking it was the resolution change as it doesn't happen when I boot up without the external monitor.

Could the new NV_robustness_video_memory_purge extension be used to detect when to trigger an update?

Probably. There're mentions it'd only fire on FBOs, but since those would likely go alongside.
Unfortunately it's not even (yet) linked in https://developer.nvidia.com/nvidia-opengl-specs so far (bleeding edge beta feature)

Actually, I have not "broken glass effect" (as my screencast showed) but however I still have "noise" in all windows till I resize them.

> Unfortunately it's not even (yet) linked in https://developer.nvidia.com/nvidia-opengl-specs so far (bleeding edge beta feature)

I got contacted by an NVIDIA dev and have a copy of the spec.

So yes, most likely the new extension will help, but I don't know yet how we can best make use of it. Probably just restarting the compositor should do the trick (it's overkill, but better safe than sorry).

Once we reliably get aware of it, its time to wipe fbo & vbo - it's what already happens for vbo's atm, just based on a hack interpreting a GL error (ie. when it's actually too late)

As long as we don't map the textures, that should be fine. The driver should™ be able to fix the texture ids on its own.

Removing person from CC list per abuse reports from Microsoft.

Created attachment 99461 [details]
Labels of desktop items in Folder View are replaced with colorful noise.

This is one of only two effects I've noticed on my system, labels of desktop files replaced with noise. This, and text has at least once been missing on the lock screen after coming back from standby mode.

Comment on attachment 99461 [details]
Labels of desktop items in Folder View are replaced with colorful noise.

Replying to this from a email I received re: Bug 344326. I get this as well, and while he mentioned the missing text on the lock screen, I also sometimes get missing text on the clock widget on my toolbar. I'll have 7:4 instead of 7:42 or whatever, and I have yet to figure out a way to get it to come back short of logging out. (Ctrl+Shift+F12, no dice.) I get the scrambled much less frequently now. Usually only when changing screen modes for a game/whatever instead of when resuming from sleep/suspend.

JSG

It's probably the same issue but here affects the GL context in plasmashell (the desktop process)
Anything you do on kwin (incl. restarting the compositor) has thus no effect.

=> You'll have to restart plasmashell ("pkill plasmashell; sleep 1; plasmashell &") to get rid of that, though there's suggestion that the most recent™ nvidia drivers do no longer expose this behavior.

Cool. Makes me look forward to the next nVidia driver.

JSG

Hi I am using;
Linux Mint 17.3 KDE 64bits
Kernel 3.13.0-87-generic 
NVidia 340.96 (and have try other versions of it too)
Xorg 11.0

And sometimes when put computer on standby when wakes up every things looks fine except blinks a lot and it is very annoying, so have log off or kill xserver in order to stop the blinking.

Regards,
   Alonso Murillo.

Shouldn't the title be changed to "Black or corrupted screen on resume from suspend with nVidia"? I had this issue with nVidia but never with Intel.

Running Manjaro 16.06.1 on an ASUS G75 laptop. nVidia 660M with the 364.19 driver. Kernel 4.6.2-1.

Since the last Manjaro update to Plasma 5.6.5, I've been getting the "corrupted screen with blinking triangles of distorted windows content" stuff again, consistently, on wake from sleep. The last version I'd sometimes get the black screen and, always, the missing text on the login screen. Now, distortion, and occasionally the KArc-Transparent theme will start up all white. Alt-Shift-F12 cures all of these issues, though I don't know about missing text this time around (distorted).

Another Manjaro issue I've noticed in case it's significant: there are some apps in this latest update that require QT 5.7, but it's still on 5.6.1. Had to downgrade a couple of them.

(In reply to JS Gibson from comment #114)
> Running Manjaro 16.06.1 on an ASUS G75 laptop. nVidia 660M with the 364.19
> driver. Kernel 4.6.2-1.
> 
> Since the last Manjaro update to Plasma 5.6.5, I've been getting the
> "corrupted screen with blinking triangles of distorted windows content"
> stuff again, consistently, on wake from sleep. The last version I'd
> sometimes get the black screen and, always, the missing text on the login
> screen. Now, distortion, and occasionally the KArc-Transparent theme will
> start up all white. Alt-Shift-F12 cures all of these issues, though I don't
> know about missing text this time around (distorted).
> 
> Another Manjaro issue I've noticed in case it's significant: there are some
> apps in this latest update that require QT 5.7, but it's still on 5.6.1. Had
> to downgrade a couple of them.

Actually just had the white KArc-Transparent problem on a machine with Intel graphics. Different issue apparently.

Created attachment 100142 [details]
Labels of desktop items in Folder View now have various glitches after wake.

We got new Nvidia drivers this weekend, but after an update, reboot, suspend and wake, I see there's very much still issues here, at least for me. The corruption is actually more "diverse" this time.

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

Still have the same issues (screen distortion, missing characters on login screen and desktop clock, black screen, distortion around file labels on desktop) less frequent now, but all still there on occasion. Manjaro 16.08, all the latest updates Plasma 5.7.4, kernel 4.7.3, nvidia driver 370.23.

Created attachment 101458 [details]
Still happening in 5.8

I don't think the lock screen is affected by this anymore, at least for me. The only thing I see affected anymore are the desktop labels.

Using Plasma 5.8 with the latest nvidia (370.28), GTX 980.

Created attachment 101902 [details]
Screenshot of KDE Desktop, folder view

I have exactly the same issues as described by Chris: labels of Desktop icons are filled with various artifacts / colorful garbage after resume from suspend to RAM.

I'm using two screens, the issues appears on both of them at the same time.

Gentoo Linux x86_64, Kernel 4.7.10, KWin 5.7.5, OpenGL compositing, NVidia binary drivers 367.57, graphics card NVidia GeForce GTX 650 Ti.

Adding "me too" to the choir.
Downstream https://bugs.mageia.org/show_bug.cgi?id=18904

The upgrade to Plasma 5.8.2 helped out a lot. The blank screen and full-screen distortion doesn't happen any more. (so far) But I still get missing characters and now the multicolor distortion in place of my avatar on the login screen. When this happens, I also get the distortion around filenames of desktop files. Doesn't happen all the time, but about 50% of the time. Manjaro 16.10, all the updates, kernel 4.8.5, nvidia 660M with 370 driver.

I just updated, rebooted, and tested suspend. Still consistently getting the desktop label issue. Still using GTX 980. I'll be more specific with versions this time:

Linux 4.8.6, Plasma/KWin 5.8.3, Nvidia 375.10

New drivers with new kernel were recently released, Linux 4.8.8 and Nvidia 375.20. The problem isn't solved yet. There is a recently active thread on Nvidia's forums about an issue with resume-from-suspend that may be related, so I posted there. https://devtalk.nvidia.com/default/topic/919984/linux/resume-from-suspend-not-working-with-980-ti-drivers-352-370-kernels-3-16-4-4/

Created attachment 102320 [details]
attachment-25211-0.html

I have not the problem anymore.

El sáb., 19 nov. 2016 a las 3:00, Chris (<bugzilla_noreply@kde.org>)
escribió:

> <https://bugs.kde.org/show_bug.cgi?id=344326>

> https://bugs.kde.org/show_bug.cgi?id=344326
<https://bugs.kde.org/show_bug.cgi?id=344326>
>
> --- Comment #124 from Chris <emailofchris@gmail.com> ---
> New drivers with new kernel were recently released, Linux 4.8.8 and Nvidia
> 375.20. The problem isn't solved yet. There is a recently active thread on
> Nvidia's forums about an issue with resume-from-suspend that may be
related, so
> I posted there.
>
https://devtalk.nvidia.com/default/topic/919984/linux/resume-from-suspend-not-working-with-980-ti-drivers-352-370-kernels-3-16-4-4/
<https://devtalk.nvidia.com/default/topic/919984/linux/resume-from-suspend-not-working-with-980-ti-drivers-352-370-kernels-3-16-4-4/>
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

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

In my case, problem is solved. Actually I have OpenSUSE Tumbleweed and same Nvidia card than with OpenSUSE 42.1

Thank you for fix this issue

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

The problem still exists for me. Linux 4.10.1, nvidia 378.13.

This bug still happens with current fedora 25 kernel (4.9.10-200) and latest nvidia driver (375.39). I'm using a GTX 960.

This bug has been in existence for TWO YEARS.

IT IS NOT GOING AWAY.

I THINK IT MIGHT BE TIME TO CHANGE THE STATUS TO CONFIRMED.

(In reply to A_Hooman_Bean from comment #130)
> This bug still happens with current fedora 25 kernel (4.9.10-200) and latest
> nvidia driver (375.39). I'm using a GTX 960.
> 
> This bug has been in existence for TWO YEARS.
> 
> IT IS NOT GOING AWAY.
> 
> I THINK IT MIGHT BE TIME TO CHANGE THE STATUS TO CONFIRMED.

If this forum had "slow clap" emojis, I'd send you three of them.

Manjaro 17 KDE, all the updates, kernel 4.10.1, Plasma 5.9.3, Nvidia 660M GTX driver 375.39

> IT IS NOT GOING AWAY.
> 
> I THINK IT MIGHT BE TIME TO CHANGE THE STATUS TO CONFIRMED.

The confirmed state has no meaning in KDE's bug tracker instance. We 
don't look at the state at all.

Why is this bug not getting fixed? Because it's an NVIDIA specific issue 
and requires NVIDIA hardware. The possible fix requires an NVIDIA 
specific OpenGL extension. Which means we need to implement NVIDIA 
specific code on NVIDIA hardware.

I'm sorry, but most devs don't have NVIDIA hardware. I do not, because 
for years all I could buy is Intel as NVIDIA doesn't support Wayland.

If you want that fixed, find a dev with an NVIDIA device or ask NVIDIA 
to provide the patch. From what I understand the change wouldn't require 
much, but without the hardware one cannot test.

I'm not a KDE dev and I completely agree with Martin. It doesn't seem fair to see KDE responsible for the behavior of a closed-source program like nvidia. KDE devs did what the could (and I'm sure they will) but this issue seems to be really an nvidia problem.

> I'm sorry, but most devs don't have NVIDIA hardware. I do not, because
> for years all I could buy is Intel as NVIDIA doesn't support Wayland.

Would it help if you (or someone else from the developers) are donated money for a Nvidia card?

(In reply to Martin Gräßlin from comment #132)
> If you want that fixed, find a dev with an NVIDIA device or ask NVIDIA 
> to provide the patch. From what I understand the change wouldn't require 
> much, but without the hardware one cannot test.

If that's the only issue, I'm happy to bring you various NVIDIA cards to the next Akademy. Most of them aren't worth a penny anymore, anyway.

> Would it help if you (or someone else from the developers) are donated
> money
> for a Nvidia card?

At least I am not interested as NVIDIA doesn't work on Wayland

>> If you want that fixed, find a dev with an NVIDIA device or ask
> NVIDIA
>> to provide the patch. From what I understand the change wouldn't
> require
>> much, but without the hardware one cannot test.
> 
> If that's the only issue, I'm happy to bring you various NVIDIA cards
> to the
> next Akademy. Most of them aren't worth a penny anymore, anyway.

That is not what I wrote. I am not interested in NVIDIA hardware as it 
doesn't work on Wayland. I'm not going to switch to X11 to fix an NVIDIA 
specific issue.

OK, so, what you're saying is that KDE is unsupoorted on Nvidia, which is probably the most commonly used display hardware.

And it also appears you're not interested in anything besides wayland. So KDE is no longer supported under Xorg.

So, KDE is designed to work for a compositor noone uses, on hardware noone uses.

Nice work guys.

You're not serious though are you. You must be trolling me. Lol. Much hilarious.

I should add, that accordign to nvidia, wayland is supported on nvidia kepler chipsets and up. So that's the last generation of nvidia cards, and the latest (maxwell).

So you wayland guys can stumble out of the darkness now, and into the light.

A reminder for some people https://gomakethings.com/open-source-etiquette/

So, please stop with the sarcastic comments against developers. They are doing a great work with the resources available.

While I do agree with comment 140, but comment 138 together with comment 137 do raise an important question: what is the status of KDE@X11? Is it only supported when the issues are cross-platform (WRT KDE@Wayland)?

> OK, so, what you're saying is that KDE is unsupoorted on Nvidia, which
> is
> probably the most commonly used display hardware.
> 
> And it also appears you're not interested in anything besides wayland.
> So KDE
> is no longer supported under Xorg.

WTF ARE YOU TALKING ABOUT????????

I'm not KDE and whether I work on Wayland or not and whether I do work 
on NVIDIA specific issues has nothing to do with what KDE supports. I'm 
just one volunteer developer of many.

To anyone else here: I tend to spend my spare time on working on things 
I choose. I am not going to get a new notebook with NVIDIA hardware 
because NVIDIA has an issue. I can do better things with my spare time.

If you want the issue fixed find a dev who cares about NVIDIA. I don't. 
It's a proprietary driver and I just don't care about it. And to make it 
absolutely clear: this is MY (!) personal opinion and MY personal 
position. It is NOT (!) the position of KDE or any other KDE developer.

Dont Nvidia show any interest in supporting this project with some developer time?  Or hardware or whatever?
--To make their brand look better, they should.

Some games and CAD need proprietary drivers. My son and wife switched to AMD card, my daughter swithed to MATE.  Personally I dont mind this bug, it just looks ugly, makeing Plasma look bad for common people - that is my concern.

Why doesn't KDE's Plasma just stop using things which are known to be buggy.

The issue does not occur in Windows or some other Linux WM/desktops so there must be ways to avoid this bug.

Of course, KDE developers will come back with some idiotic response saying it's not thier job to work around bugs in software they're not responsible for, but that is utter garbage. There are bugs in all sorts of software, and successful software developers who want to produce a quality product plan or work their way around those bugs.

But KDE developers just appear not to give a damn.

To bring some constructive comments into it:

This issue is easy to fix for any C++ developer with an NVIDIA card. There is no special knowledge about KWin or OpenGL needed.

For interested devs:
Please check the documentation of the NVIDIA specific OpenGL spec: https://khronos.org/registry/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

It tells you what to do. Basically extend the method initRenderingContext in glxbackend.cpp with the new attributes specified in this spec. The code already there shows you what to do.

Once that is in KWin should restart the compositor instead crashing. This is a max of half an hour work for anybody who is affected by this problem.

In general I would like to ask you to calm down a little bit and tune down your tone. I find the behavior of some users absolutely unacceptable and not helpful. It makes me annoyed of this bug and care even less about it.

Thank you Martin, that looks like some really good information.

I apologise if my comments have seemed a bit harsh. But I see bugs languishing and sometimes I see developers making misleading statements to cover up problems & pretend they don't exist or can't be fixed or it is someone else's problem, when it isn't. 

With any open source project, all a developer has to say is they don't have the time to address something, or they have other priorities, etc, and I completely understand.

But i get angry when devs try their various cover-up tactics, because that insults the users who've reported thw problem & makes it less likely that someone else can come along & make some progress. 

Now, if you are correct, then I hope a dev will find time to fix this soon. I may even have a look at it myself, but I only occasionally have time to delve into KDE code, and it'll take me more than 30 mins for me, that's for sure.

If no dev has the time to fix this, then, if your info is correct, at least there is a chance the problem may fix itself if Nvidia do manage to progress & fix their opengl so it doesn't lose these buffers. But that could take a long time or never happen, so I'll keep my fingers Xed for a fix in KDE sometime soon.

Thanks again for contributing some vital info to this bug report.

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

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

(In reply to Martin Gräßlin from comment #145)
> To bring some constructive comments into it:
> 
> This issue is easy to fix for any C++ developer with an NVIDIA card. There
> is no special knowledge about KWin or OpenGL needed.

Thanks, I have a nvidia card and I want to get this fixed.

> 
> It tells you what to do. Basically extend the method initRenderingContext in
> glxbackend.cpp with the new attributes specified in this spec. The code
> already there shows you what to do.

You mean something like https://paste.kde.org/p1mrbm9d6 ? It seems initRenderingContext() is called only once, not after switching VT (so the patch above doesn't fix it).

> You mean something like https://paste.kde.org/p1mrbm9d6 ?

No you need to create another attribs array with the new values from the nvidia spec and do another glXCreateContextAttribsARB dance.

The part you did is the other side, though maybe not required.

@Martin: I just found out https://phabricator.kde.org/D2079, will test.

Created attachment 104860 [details]
Possible fix

@anyone affected: please rebuild kwin with this patch and report back.

(In reply to Elvis Angelaccio from comment #152)
> Created attachment 104860 [details]
> Possible fix
> 
> @anyone affected: please rebuild kwin with this patch and report back.

Please note that this will only work if OpenGL 3.1 is selected in the settings.

Thank you so much for working on it  :)

(In reply to Elvis Angelaccio from comment #152)
> Created attachment 104860 [details]
> Possible fix
> 
> @anyone affected: please rebuild kwin with this patch and report back.

I've applied the patch to my kwin ebuild (5.9.4). I've got an Nvidia 970M in my laptop with the proprietary driver 378.13 (patched for the 4.10 kernel)...

Sadly suspend-to-ram stopped working when I upgraded one of laptops SSD's (tried a few different Linux distributions - they all reboot on resume)...

Anyway I'll test with hibernation (suspend-to-disk) which does work and report back. That also resulted in screen artifacts - after resume.

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

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

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

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

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

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

Hi,

I have been facing this problem from the first time I tried KDE, which is 3 months ago. I tried many different nvidia drivers, waiting for each kde and nvidia driver updates. Still the same issue.

I have recorded videos showing-
-problem when using nvidia driver
-working fine with intel graphics

Find the recordings here: https://drive.google.com/open?id=0B3aF7WUKvMO4TE5fVlFobXg3RzA

Please look into this and fix it asap. Note that it works with open soure nouveau driver.

Thanks,
Jones

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

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

I created a patch for the issue at https://phabricator.kde.org/D6344

I do not have an NVIDIA card, so I cannot test. It is based upon the information which we have in this bug report. Please test whether it works.

(In reply to Martin Flöser from comment #165)
> I created a patch for the issue at https://phabricator.kde.org/D6344
> 
> I do not have an NVIDIA card, so I cannot test. It is based upon the
> information which we have in this bug report. Please test whether it works.

I would like to test it. Can anyone compile it for openSUSE with frameworks 5.35 / plasma 5.10.2 and Qt5.9?
Or any hint how to compile?

Thank you!

I can test it next week.

(In reply to Martin Flöser from comment #165)
> I created a patch for the issue at https://phabricator.kde.org/D6344
> 
> I do not have an NVIDIA card, so I cannot test. It is based upon the
> information which we have in this bug report. Please test whether it works.

Martin

I get similar results - as with your previous patch (see comments 151-153).

Currently testing with a Nvidia GTX 970M + driver 381.22 with KWin 5.10.2.
Tested with the KWin compositor enabled and using OpenGL 3.1 rendering backend.

WITH the patch and after a suspend to disk the only "damaged surfaces" are things like VDPAU accelerated video playback and Chrome/Chromium content (probably GL accelerated). Moving the Chromium Window is enough to clear the artefacts in the latter case. Pretty similar to Windows IMHO. 

WITHOUT the patch significant portions of the screen are reproduceably degraded / damaged. E.g. KWin decorations, etc.

So (personally) I'd say ship it!"!

Thanks for working on this issue... Despite your antithesis towards Nvidia!

Git commit 97fa72ee48b7525e722822e7d7d41bb08343e337 by Martin Flöser.
Committed on 26/06/2017 at 20:05.
Pushed by graesslin into branch 'Plasma/5.10'.

[platforms/x11] Add support for GLX_NV_robustness_video_memory_purge

Summary:
Based on earlier phab-request D2079. Adds the nvidia memory purge
extension to the robust context creation.
FIXED-IN: 5.10.3

Test Plan: Only compile tested as I don't have an NVIDIA card.

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D6344

M  +37   -4    plugins/platforms/x11/standalone/glxbackend.cpp

https://commits.kde.org/kwin/97fa72ee48b7525e722822e7d7d41bb08343e337

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

Bug 382115 is from Plasma 5.10.3

(In reply to Christoph Feck from comment #171)
> Bug 382115 is from Plasma 5.10.3

@Christoph: this change here is for KWin. That bug is a rendering issue in Plasma. A change in KWin cannot fix the rendering issue in Plasma.

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

Thanks a lot to all KDE contributors working towards the solution of this long standing issue. I have had this exact same suspend issue for 2 years (since switching from KDE 4 to Plasma 5). I understand that it should be fixed starting with the 5.10.3 release, however it doesn't seem to be the case for me, so perhaps I have missed some important setting to enable the fix.

I use the "Folder View" plasmoid on my Plasma desktop, and in my case, the display artifacts are most obvious on the icon texts, which become some kind of random noise after each suspend/resume cycle, and until I mouse-drag them to force a redraw. After a few (~ 5) suspend/resume cycles, the contents of background windows also randomly tend to go black when they are not in focus (but just briefly moving the mouse over the affected window instantly redraws its contents: I use "focus follows mouse" strategy btw). To get rid of this behaviour, I need to completely log off and back in.

My current setup is OpenSuSE Leap 42.2 with a GTX 560 Ti graphics card and latest proprietary driver (384.59). I currently run Plasma & KWin 5.10.4 (previously tried 5.10.3 as well) and Frameworks 5.36.0. I use the Plasma packages from the KDE:Frameworks5 repository and Qt 5.9.1 from the KDE:Qt5 repository.

The compositor is set to use the OpenGL 3.1 rendering engine @ 2560 x 1440 (if that matters) with "Breeze" decorations.

What I observed since switching to 5.10.3 and then 5.10.4 is that a new KWin notification pops up each time I resume from sleep, saying that desktop effects have been reset following restart of the graphics engine (rough translation from French). But besides this the display artifacts are still there, exactly the same.

Thanks in advance for advice.

Thanks a lot to all KDE contributors working towards the solution of this long standing issue. I have had this exact same suspend issue for 2 years (since switching from KDE 4 to Plasma 5). I understand that it should be fixed starting with the 5.10.3 release, however it doesn't seem to be the case for me, so perhaps I have missed some important setting to enable the fix.

I use the "Folder View" plasmoid on my Plasma desktop, and in my case, the display artifacts are most obvious on the icon texts, which become some kind of random noise after each suspend/resume cycle, and until I mouse-drag them to force a redraw. After a few (~ 5) suspend/resume cycles, the contents of background windows also randomly tend to go black when they are not in focus (but just briefly moving the mouse over the affected window instantly redraws its contents: I use "focus follows mouse" strategy btw). To get rid of this behaviour, I need to completely log off and back in.

My current setup is OpenSuSE Leap 42.2 with a GTX 560 Ti graphics card and latest proprietary driver (384.59). I currently run Plasma & KWin 5.10.4 (previously tried 5.10.3 as well) and Frameworks 5.36.0. I use the Plasma packages from the KDE:Frameworks5 repository and Qt 5.9.1 from the KDE:Qt5 repository.

The compositor is set to use the OpenGL 3.1 rendering engine @ 2560 x 1440 (if that matters) with "Breeze" decorations.

What I observed since switching to 5.10.3 and then 5.10.4 is that a new KWin notification pops up each time I resume from sleep, saying that desktop effects have been reset following restart of the graphics engine (rough translation from French). But besides this, display artifacts are still there, exactly the same.

Thanks in advance for advice.

I can confirm this bug still exists in Plasma 5.10.4. Rather than logging off and on, though, you can run this command to restart plasma:

kquitapp5 plasmashell && plasmashell

I make a shortcut with this command on my desktop so that when I resume from sleep, I can just run this to get rid of the corrupted graphics.

** My System **
OS: KDE Neon 5.10.4 64-bit (Plasma Desktop 5.10.4, KDE Frameworks 5.36.0, Qt 5.9.1)
Linux Kernel: 4.10.0.30-generic
CPU: Intel Core i7 930 (2.8 GHz quad-core)
RAM: 12GB DDR3
Video: NVIDIA GeForce GTX 970 w/ 4GB RAM (PCI Express)
NVIDIA video driver: 375.66

(In reply to S. Christian Collins from comment #176)
> I can confirm this bug still exists in Plasma 5.10.4. Rather than logging
> off and on, though, you can run this command to restart plasma:
> 
> kquitapp5 plasmashell && plasmashell
> 
> I make a shortcut with this command on my desktop so that when I resume from
> sleep, I can just run this to get rid of the corrupted graphics.

Isn't there any way then that plasma can be notified (or detect) that there's been a suspend/resume, so plasma can just restart itself?

Please note that this bug report was about KWin crashing after suspend. It is not about any issues in Plasma. If you have problems with Plasma please report a new bug against product Plasma.

We only track one problem per bug report.

Please also do not use this bug report for support questions. Thank you!

(In reply to Martin Flöser from comment #178)
> Please note that this bug report was about KWin crashing after suspend. It
> is not about any issues in Plasma. If you have problems with Plasma please
> report a new bug against product Plasma.
> 
> We only track one problem per bug report.

A bug was reported. It was initially atrtributed to Kwin. Eventually Plasma got involved. I don't know the details, I'm just hoping the bug can be fixed. It looks like people thought it was fixed at last, but it seems it may not quite be fixed after all.

It looks like Kwin & Plasma 5.10.4 have arrived in F26 so I'm just going to update from 5.10.1 and see how it looks on my system.

> A bug was reported. It was initially atrtributed to Kwin. Eventually Plasma
> got involved. I don't know the details, I'm just hoping the bug can be
> fixed. It looks like people thought it was fixed at last, but it seems it
> may not quite be fixed after all.

If you want the issue to get fixed in Plasma, report it against Plasma. Once again: this bug report here was about the crash in KWin with NVIDIA and nothing else. We have one bug report per issue. If there are multiple issues multiple bug reports are required.

I'm sure you want the issue to get fixed. Thus create a new bug report. Reporting the issue in this bug report just won't get the issue fixed. No Plasma developer reads this bug report as it is on product KWin. Even if it were reassigned no Plasma dev would read it as it has two years of comments about KWin. It needs a dedicated report for Plasma. So please do that and stop reporting here, it is not helpful.

(In reply to Martin Flöser from comment #180)
> > A bug was reported. It was initially atrtributed to Kwin. Eventually Plasma
> > got involved. I don't know the details, I'm just hoping the bug can be
> > fixed. It looks like people thought it was fixed at last, but it seems it
> > may not quite be fixed after all.
> 
> If you want the issue to get fixed in Plasma, report it against Plasma. Once
> again: this bug report here was about the crash in KWin with NVIDIA and
> nothing else. We have one bug report per issue. If there are multiple issues
> multiple bug reports are required.
> 
> I'm sure you want the issue to get fixed. Thus create a new bug report.
> Reporting the issue in this bug report just won't get the issue fixed. No
> Plasma developer reads this bug report as it is on product KWin. Even if it
> were reassigned no Plasma dev would read it as it has two years of comments
> about KWin. It needs a dedicated report for Plasma. So please do that and
> stop reporting here, it is not helpful.

Dude. I don't know or care whether the bug is in Kwin or Plasma.
Forget I even mentioned Plasma.

The bug is not a "crash" in Kwin. It is about corrupted buffer objects, eg text under icons after suspend/resume. There is no "crash".

Read the recent comment just above from Pierre. Whatever this bug is, whether it's Kwin, or Plasma, it appears that it is NOT fixed. Sorry.

I am not trying to associate some new bug with this old report. I'm only back here because it looked like this bug was fixed, horray! And then Pierre reported that it seems not fixed. 

I have updated my F26 system and I am about to see whether it's fixed for me, and will report back shortly.

Tested with Kwin & Plasma 5.10.4-1, Nvidia 375.66, on Nvidia GTX960.

Not fixed. Suspend and resume still corrupts text under icons.

Sorry.

Pierre Baldensperger, S. Christian Collins, and myself have now all confirmed that the bug is not fixed in Kwin 5.10.4.

Please re-open.
Thanks.

A_Hooman_Bean, the bug we are experiencing is not in KWin, but affects the plasma desktop containment, therefore it is not the same bug.

From what I understand, this is something that NVIDIA needs to really fix, but any temporary workaround will need to come from Qt, since it affects their code. 

Here's the upstream bug report: https://bugreports.qt.io/browse/QTBUG-56610

(In reply to S. Christian Collins from comment #184)
> A_Hooman_Bean, the bug we are experiencing is not in KWin, but affects the
> plasma desktop containment, therefore it is not the same bug.
> 
> From what I understand, this is something that NVIDIA needs to really fix,
> but any temporary workaround will need to come from Qt, since it affects
> their code. 
> 
> Here's the upstream bug report: https://bugreports.qt.io/browse/QTBUG-56610

Aah. Ok thanks for clarifying that! 

So this report has managed to resolve a different bug in Kwin that was also causing issues with icon text etc.

Well, thank you Kwin devs for resolving your issue. I apologise for the confusion, but these two bugs have very similar symptoms.

Now, I just wish Nvidia or QT would resolve the remaining issue with icon text corruption after suspend/resume. 

Of course Qt are saying it's an Nvidia problem, and it does seem to be so, but Nvidia have apparently concluded it's hard to fix the underlying issue, so have provided an extension which enables a workaround, but that's not good enough for Qt are too lazy to use it.

Groan. I am just so sick of this.

Sorry for any misunderstanding.
It seems that I have followed this on the cc-list for months without realizing it was about another issue.
I was pretty sure that this bug report was about the same issue I have been experiencing for two years.
It also seems that I have not understood what the "other" bug was about (the one that was fixed in 5.10.3) and that this "other" one (fortunately) never showed up on my machine.

I admit that I fail to see how exactly Plasma and KWin share the graphics work, but I assumed that KWin was the Plasma component in charge of all the display and compositing operations, and the mentioned artifacts as well as triggering mechanism (icon text as noise, black windows and repaint issues after suspend / resume) seemed very similar to what I get, which look a lot like a low-level display / compositing issue. So I never suspected that it could be a Plasma issue, all the more since it also affects "plain regular" windows from any application (not just KDE or Plasma).

Now I see the pointer to the upstream Qt bug, which itself assumes that there is a bug in the NVIDIA drivers, so it may not be a KDE bug after all... That sounds definitely possible.

I also want to (again) thank the contributors who worked on the issue even though some of them had to do it "blindly" because they lacked NVIDIA hardware to reproduce the problem.

I (and maybe other bug triagers) have incorrectly duplicated tickets about the Plasma issue to this ticket. See comment #172.

Sorry for any inconvenience this has caused.

For plasma (shell, kscreenlocker, whatever) please follow 364766.

If someone could test the (somewhat messy) patch there, that would be very appreciated.

Kubuntu 19.04

KDE 5.15
Qt 5.12
Nvidia GTX 1060 (418 driver)

https://hostingkartinok.com/show-image.php?id=37f0bda79a62ad503d08309a6f5595d5

Bug still present. I try nouveau driver, but without success.

Can we reopen this?

This bug is only for KWin. Issues in other applications are handled in other reports.