Bug 443951

Created attachment 142568 [details]
qdbus org.kde.KWin

Please post the output of

  qdbus org.kde.KWin /KWin supportInformation

Based on the video, it seems like it's nvidia.

> After a period of time, compositing will go completely wonky.
Have you noticed anything that is more likely to trigger these visual artifacts?

Can you also confirm that restart kwin fixes it?

Created attachment 142572 [details]
qdbus org.kde.KWin /KWin supportInformation

(In reply to Vlad Zahorodnii from comment #3)
> Based on the video, it seems like it's nvidia.
> 
> > After a period of time, compositing will go completely wonky.
> Have you noticed anything that is more likely to trigger these visual
> artifacts?

Playing Games that trigger disabling the compositor (by using the "disable desktop effects" toggle in Lutris), so basically enabling and disabling the compositor, and watching videos in browsers. 

>Can you also confirm that restart kwin fixes it?

I'll try and trigger it and see if kwin_x11 --replace fixes it.

Okay, so I can force it to happen every time by switching to a TTY and back. 

kwin_x11 --replace fixes it *most* times, once it caused everything to go wonky and I had to log out and back in, but yeah it generally fixes it. 

But before 5.23 I could change to a TTY and back and this wouldn't happen.

Alt-Tabbing out of Control (the game) triggered it again. kwin_x11 --replace fixed it.

(In reply to Matt McDonald from comment #8)
> Alt-Tabbing out of Control (the game) triggered it again. kwin_x11 --replace
> fixed it.

Actually just disabling and re-enabling compositing with Alt+Shift+F12 causes it. It wasn't the alt-tabbing out of the game, it was that I have desktop effects disabled and re-enabled upon startup and exit of the game.

Can you please check a couple more things?

* does this glitch show up with KWIN_USE_BUFFER_AGE=0 envvar?
* does this glitch show up with fullscreen repaints? (in order to force fullscreen compositing, go to compositor settings and select "full screen repaints" tearing prevention)
* when the glitch occurs, can you check kwin's logs?

(In reply to Vlad Zahorodnii from comment #10)
> Can you please check a couple more things?
> 
> * does this glitch show up with KWIN_USE_BUFFER_AGE=0 envvar?
> * does this glitch show up with fullscreen repaints? (in order to force
> fullscreen compositing, go to compositor settings and select "full screen
> repaints" tearing prevention)
> * when the glitch occurs, can you check kwin's logs?


 - I can't seem to force it with fullscreen repaints enabled. Obviously for performance reasons I hope to not have to keep that option enabled. 

 - I put `KWIN_USE_BUFFER_AGE=0 in my /etc/environment and will try to force it (without full screen repaints) next reboot. 

 - Actually I just got out of Doom Eternal and the bug appeared (obviously this was without full screen repaints) so I have the journalctl logs from that moment, but there doesn't seem to be much. I'll upload the relevant section as an attachment.

Created attachment 142706 [details]
Journalctl log section

Oh I'm also seeing a really horrible new bug where right-clicking tray icons on the system tray to bring up their menu will often cause the desktop to lose it's mind. Like, open windows will rapidly rotate in and out of focus, I'll get 20 "Configure Desktop and Wallpaper" windows opening (as if I right-clicked and selected "Configure Desktop and Wallpaper" a dozen or more times), I can't click on any window or do anything for like 3 minutes, I have to just wait for it to stop having a nervous breakdown. I'm not sure if this is related or not, but this also never once happened before 5.23 and I've seen it happen about twice a day since the upgrade (and it happens on both 470 and 495 Nvidia drivers). I'll try to get logs from that next time it happens too.

(In reply to Matt McDonald from comment #13)
> Oh I'm also seeing a really horrible new bug where right-clicking tray icons
> on the system tray to bring up their menu will often cause the desktop to
> lose it's mind. Like, open windows will rapidly rotate in and out of focus,
> I'll get 20 "Configure Desktop and Wallpaper" windows opening (as if I
> right-clicked and selected "Configure Desktop and Wallpaper" a dozen or more
> times), I can't click on any window or do anything for like 3 minutes, I
> have to just wait for it to stop having a nervous breakdown. I'm not sure if
> this is related or not, but this also never once happened before 5.23 and
> I've seen it happen about twice a day since the upgrade (and it happens on
> both 470 and 495 Nvidia drivers). I'll try to get logs from that next time
> it happens too.

Maybe file another bug report about this one.

Okay so full screen repaints isn't cutting it. After selecting the option earlier, I couldn't force the bug by switching to a TTY and back, but after I rebooted to test KWIN_USE_BUFFER_AGE=0 in my /etc/environment, and switching back and forth between "Automatic," "Only when cheap," and "Full screen repaints," I saw the issue on all three - which also means that KWIN_USE_BUFFER_AGE=0 doesn't help. 

kwin_x11 --replace still works to fix it. 

I'll attach the journalctl messages from this go-round.

Created attachment 142734 [details]
Journalctl take 2

I have this issue as well on my laptop with Intel HD 4000 graphics and two desktop machines with an RTX 2080 Super and GTX 970. Sometimes this bug can cause an entire monitor to start flashing rapidly. I cannot recreate it consistently but it started happening after the 5.23 update.

This is a rather serious issue for me as I am photosensitive and flashing can cause medical problems.

Can somebody verify whether setting `NVreg_PreserveVideoMemoryAllocations=1` makes any difference? https://bugs.kde.org/show_bug.cgi?id=443341#c7

(In reply to Vlad Zahorodnii from comment #18)
> Can somebody verify whether setting `NVreg_PreserveVideoMemoryAllocations=1`
> makes any difference? https://bugs.kde.org/show_bug.cgi?id=443341#c7

Maybe I should have been more clear but I don't suspend or hibernate my system, so that parameter doesn't apply.

I mean I can try it just for the sake of it but that parameter is specifically for preserving VRAM for suspend/resume, and I've never suspended this PC once.

(In reply to Matt McDonald from comment #9)
> Actually just disabling and re-enabling compositing with Alt+Shift+F12
> causes it. It wasn't the alt-tabbing out of the game, it was that I have
> desktop effects disabled and re-enabled upon startup and exit of the game.

I've installed an nvidia video card on my machine and can't reproduce the bug by toggling compositing. Some apps don't handle graphics reset properly, but that seems the case even with kwin 5.22.

Okay, it just happened to me. In order to reproduce the issue I pressed alt-tab to show and hide the task switcher, switched to another vt, switched back to plasma and clicked "Edit Current Profile..." in konsole

I only had two apps open - firefox and konsole.

Yeah, it has something to do with window thumbnails. In 5.23.0, we changed how window thumbnails are rendered (for the new overview effect and to avoid having detached thumbnails in the task switcher).

With relevant code being commented out, I see no flickering...

I just hit alt-tab, then opened Konsole -> right-click -> Edit current profile then toggled compositing on and off and caused the issue as well. Yeah after my initial comment saying I could force it just by toggling compositing I found that it doesn't do it every time, but yeah...

Aha, I have a theory why it happens. The WindowThumbnail item will delay the destruction of the thumbnail texture to avoid destroying a texture which is still in use.

On the other hand, the GLTexture seems to have a ref-counted VBO (https://invent.kde.org/plasma/kwin/-/blob/bd3d275293821acd490a8d4e28e59860b8f0bae5/src/libkwineffects/kwingltexture.cpp#L295), which is destroyed when the last texture is gone.

Since the thumbnail texture can be alive even after compositing has been re-initialized. KWin can continue using old VBO, which is long time gone.

Just to confirm my theory, I made the WindowThumbnail destroy the thumbnail texture immediately and it seems like there are no glitches anymore..

Correction: m_vbo is an instance property. The issue seems to affect s_fbo. With the following patch

diff --git a/src/libkwineffects/kwingltexture.cpp b/src/libkwineffects/kwingltexture.cpp
index de08572ef..3e3c0fb8d 100644
--- a/src/libkwineffects/kwingltexture.cpp
+++ b/src/libkwineffects/kwingltexture.cpp
@@ -334,6 +334,10 @@ void GLTexturePrivate::cleanup()
 {
     s_supportsFramebufferObjects = false;
     s_supportsARGB32 = false;
+    if (s_fbo) {
+        glDeleteFramebuffers(1, &s_fbo);
+        s_fbo = 0;
+    }
 }
 
 bool GLTexture::isNull() const

I can't reproduce the bug.

(In reply to Vlad Zahorodnii from comment #27)
> Correction: m_vbo is an instance property. The issue seems to affect s_fbo.
> With the following patch
> 
> diff --git a/src/libkwineffects/kwingltexture.cpp
> b/src/libkwineffects/kwingltexture.cpp
> index de08572ef..3e3c0fb8d 100644
> --- a/src/libkwineffects/kwingltexture.cpp
> +++ b/src/libkwineffects/kwingltexture.cpp
> @@ -334,6 +334,10 @@ void GLTexturePrivate::cleanup()
>  {
>      s_supportsFramebufferObjects = false;
>      s_supportsARGB32 = false;
> +    if (s_fbo) {
> +        glDeleteFramebuffers(1, &s_fbo);
> +        s_fbo = 0;
> +    }
>  }
>  
>  bool GLTexture::isNull() const
> 
> I can't reproduce the bug.


I just built KWin with that patch and I can't get the bug to trigger as of right now. I've alt-tabbed and opened windows and disabled and enabled compositing like crazy, and I can't reproduce it anymore. I'll obviously keep trying and will report what I find.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1564

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

Git commit fda7e150df207d512b60ba4062be5edafc61d539 by Vlad Zahorodnii.
Committed on 25/10/2021 at 10:00.
Pushed by vladz into branch 'master'.

kwineffects: Fix destruction of s_fbo with shared GLTexture objects

The WindowThumbnail item uses the GLTexture class. In order to destroy
the thumbnail texture, the item will schedule a destroy job.

This means that the GLTexture can be alive during or after graphics
reset.

On the other hand, as an implementation detail, GLTexture::clear() may
allocate a framebuffer object, which is going to be destroyed together
with the last texture.

Given that window thumbnail textures can be still alive after a graphics
reset and the fact that GLTexturePrivate::s_fbo gets destroyed when the
last texture is destroyed, kwin can end up trying to clear a decoration
texture with now defunct s_fbo.

Since the old old s_fbo is inert, the glBindFramebuffer() function will
fail and the glClear() operation will affect the default framebuffer,
thus leading to black flickering visual artifacts.

In order to fix that issue, this change makes GLTexture destroy s_fbo
unconditionally in GLTexturePrivate::cleanup() which is called whenever
OpenGL stuff is about to tear down, e.g. due to graphics reset, etc.

M  +4    -7    src/libkwineffects/kwingltexture.cpp
M  +0    -1    src/libkwineffects/kwingltexture_p.h

https://invent.kde.org/plasma/kwin/commit/fda7e150df207d512b60ba4062be5edafc61d539

Git commit 1b1aef83b7ebf388c1d9ce6b8925eb89347c4a00 by Vlad Zahorodnii.
Committed on 25/10/2021 at 10:29.
Pushed by vladz into branch 'Plasma/5.23'.

kwineffects: Fix destruction of s_fbo with shared GLTexture objects

The WindowThumbnail item uses the GLTexture class. In order to destroy
the thumbnail texture, the item will schedule a destroy job.

This means that the GLTexture can be alive during or after graphics
reset.

On the other hand, as an implementation detail, GLTexture::clear() may
allocate a framebuffer object, which is going to be destroyed together
with the last texture.

Given that window thumbnail textures can be still alive after a graphics
reset and the fact that GLTexturePrivate::s_fbo gets destroyed when the
last texture is destroyed, kwin can end up trying to clear a decoration
texture with now defunct s_fbo.

Since the old old s_fbo is inert, the glBindFramebuffer() function will
fail and the glClear() operation will affect the default framebuffer,
thus leading to black flickering visual artifacts.

In order to fix that issue, this change makes GLTexture destroy s_fbo
unconditionally in GLTexturePrivate::cleanup() which is called whenever
OpenGL stuff is about to tear down, e.g. due to graphics reset, etc.


(cherry picked from commit fda7e150df207d512b60ba4062be5edafc61d539)

M  +4    -7    src/libkwineffects/kwingltexture.cpp
M  +0    -1    src/libkwineffects/kwingltexture_p.h

https://invent.kde.org/plasma/kwin/commit/1b1aef83b7ebf388c1d9ce6b8925eb89347c4a00

I'm coming from bug 443906, which is presumably the same thing,
tried running Plasma/5.23 branch which contains the patch,
still managed to run into full screen flickering after a while.
(unless my previous `kwin_x11 --replace` experiments somehow also at fault)

Please make sure that it's not a packaging issue and you actually run kwin with the fix.

I'm using PKGBUILD from Arch repos as a reference and doing essentially the following:
- `cmake -B build -S kwin -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LIBEXECDIR=lib`
- `cmake --build build -j $(nproc)`
- `DESTDIR=install cmake --install build`
- `cd install/usr/bin`
- `./kwin_x11 --replace`

Did a clean clone and added the print in the `main_x11.cpp` as a sanity check when running the binary, will report back once I run into flickering again.

If you see flickering again, please describe how to reproduce the issue. The hardest part with this sort of bugs is finding a reliable way to reproduce the bug.

Well that was fast, got the flickering again.

Yeah, I'm not exactly sure whats causing it, sometimes it takes hours, sometimes shows up in 10 or so minutes.

Just doing the usual window manipulation (opening, moving, resizing, minimizing, maximizing). 
Occasionally toggling mpv border, but mostly for checking if flickering happens. (toggling it on will trigger the flicker if kwin is flicker-happy)

Right now flickering seemingly started right after Thunderbird notification, but trying to send some with `notify-send` doesn't seem to break it.

I tried "bisecting" but since reproduction is flaky, only managed to confirm that it still seem to happen on d543c0dff6b5ad287615d6435a2a2dfd85e4085c (using v5.22.90 tag as a base)

Can you reproduce the bug by following https://bugs.kde.org/show_bug.cgi?id=443951#c22 or https://bugs.kde.org/show_bug.cgi?id=443951#c25 ?

Tried following the second one, alt-tabbing and then toggling compositing off and on seems to be enough to trigger it. After that if I toggle mpv border or resize a window the flickering starts.

(In reply to Awakening from comment #39)
> Tried following the second one, alt-tabbing and then toggling compositing
> off and on seems to be enough to trigger it. After that if I toggle mpv
> border or resize a window the flickering starts.

That's odd... I'm most certainly sure that this bug should be fixed. Does your Plasma/5.23 branch include 1b1aef83b7ebf388c1d9ce6b8925eb89347c4a00?

Pretty sure it does, not sure if stdout is redirected somewhere else in there, but I'm not hitting the print I put in `GLTexturePrivate::cleanup` or constructor.

(In reply to Awakening from comment #41)
> Pretty sure it does, not sure if stdout is redirected somewhere else in
> there, but I'm not hitting the print I put in `GLTexturePrivate::cleanup` or
> constructor.

Oh, that's a good clue. It sounds like kwin uses wrong libkwinglutils for some reason. If you use qDebug(), it will be printed in stdout.

In either case, 5.23.2 will be released tomorrow (10/26). I suggest to wait until it's released. If the issue is still there, file a new bug report.

> It sounds like kwin uses wrong libkwinglutils for some reason.

Oops, it is indeed my "packaging" fault. 

`lld` shows kwin using my system libs, instead of local ones. 

Pointing it to local libs with `LD_LIBRARY_PATH=./../lib ./kwin_x11 --replace`, I can't reproduce the flickering after an alt-tab, and actually see the prints.

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

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

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

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

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

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

I am on openSUSE TW, how can I check if this fix has made it is? I am still seeing this problem today, which seems to have shown up last week.

I made a quick video, but unable to capture the flickering: https://www.youtube.com/watch?v=YMKQJ-kWfVg

Something all I need to do is open a new window and both my monitor will go into rapid flickering which is really jarring!

Operating System: openSUSE Tumbleweed 20211025
KDE Plasma Version: 5.23.1
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.14-1-default (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2

(In reply to Rajinder Yadav from comment #50)
> I am on openSUSE TW, how can I check if this fix has made it is? I am still
> seeing this problem today, which seems to have shown up last week.
> 
> I made a quick video, but unable to capture the flickering:
> https://www.youtube.com/watch?v=YMKQJ-kWfVg
> 
> Something all I need to do is open a new window and both my monitor will go
> into rapid flickering which is really jarring!
> 
> Operating System: openSUSE Tumbleweed 20211025
> KDE Plasma Version: 5.23.1
> KDE Frameworks Version: 5.87.0
> Qt Version: 5.15.2
> Kernel Version: 5.14.14-1-default (64-bit)
> Graphics Platform: X11
> Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
> Memory: 62.7 GiB of RAM
> Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2



>Version Fixed In: 5.23.2


...


> Operating System: openSUSE Tumbleweed 20211025
> KDE Plasma Version: 5.23.1

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

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