When using kwin 3d compositing, windows such as firefox will "freeze" and clicking or scrolling will do nothing to change their contents. It happens randomly and I can't seem to figure out what the exact trigger is. If I turn off the 3d compositing or do kwin_x11 --replace command, the window will unfreeze, so it seems to be a kwin thing. Reproducible: Sometimes
Not necessarily, esp. not in case of firefox. See the two linked bugs. One is mostly about the intel driver and a broken buffer_age support. Try export KWIN_USE_BUFFER_AGE=0; kwin_x11 --replace & The other one is about a specific MESA version. Please also attach the output of qdbus org.kde.KWin /KWin supportInformation while the compositor is active.
KWin Support Information: The following information should be used when requesting support on e.g. http://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like http://paste.kde.org instead of pasting into support threads. ========================== Version ======= KWin version: 5.1.2 Qt Version: 5.4.0 Operation Mode: X11 only Options ======= focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false showDesktopIsMinimizeAll: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: commandActiveTitlebar1: 0 commandActiveTitlebar2: 1 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777250 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 unredirectFullscreen: false glSmoothScale: 1 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 0 glPlatformInterface: Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: yes Number of Screens: 1 Screen 0 Geometry: 0,0,1920x1080 Decoration ========== Current Plugin: aurorae Shadows: yes Alpha: yes Announces Alpha: yes Tabbing: no Frame Overlap: yes Blur Behind: yes Compositing =========== Compositing is active Compositing Type: OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2 OpenGL version string: 3.1.0 NVIDIA 346.16 OpenGL platform interface: GLX OpenGL shading language version string: 1.40 NVIDIA via Cg compiler Driver: NVIDIA Driver version: 346.16 GPU class: Unknown OpenGL version: 3.1 GLSL version: 1.40 X server version: 1.16.1 Linux kernel version: 3.16.6 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --------------- zoom dimscreen slidingpopups kwin4_effect_login wobblywindows screenshot minimizeanimation kwin4_effect_translucency desktopgrid cubeslide cube kwin4_effect_maximize kwin4_effect_fade presentwindows highlightwindow kwin4_effect_dialogparent blur contrast logout dashboard startupfeedback screenedge kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 dimscreen: slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: wobblywindows: stiffness: 0.03 drag: 0.92 moveFactor: 0.2 xTesselation: 20 yTesselation: 20 minVelocity: 0 maxVelocity: 1000 stopVelocity: 0.5 minAcceleration: 0 maxAcceleration: 1000 stopAcceleration: 0.5 moveEffectEnabled: true openEffectEnabled: false closeEffectEnabled: false moveWobble: true resizeWobble: true screenshot: minimizeanimation: kwin4_effect_translucency: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true cubeslide: rotationDuration: 200 dontSlidePanels: false dontSlideStickyWindows: false usePagerLayout: true useWindowMoving: false cube: cubeOpacity: 0.699999988079071 opacityDesktopOnly: false displayDesktopName: true reflection: true rotationDuration: 200 backgroundColor: #000000 capColor: #eff0f1 paintCaps: true closeOnMouseRelease: true zPosition: 2271 useForTabBox: true invertKeys: false invertMouse: false capDeformationFactor: 0.0399999991059303 useZOrdering: false texturedCaps: true kwin4_effect_maximize: kwin4_effect_fade: presentwindows: layoutMode: 0 showCaptions: true showIcons: true doNotCloseWindows: false ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 150 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: kwin4_effect_dialogparent: blur: blurRadius: 13 cacheTexture: true contrast: logout: useBlur: true dashboard: brightness: 0.5 saturation: 0.5 blur: false startupfeedback: screenedge: kscreen:
> Current Plugin: aurorae Please try oxygen, or new breeze (if already available) - that's pot. a problem w/ qml.
Where is that plugin controlled from? I go to settings>workspace theme or application style and there is nothing called aurorae there, only breeze and oxygen stuff is selected. How do I know if the breeze I have is old or new? I am on opensuse 13.2, x64, and am using KDE Frameworks 5 & Plasma 5 repos from https://en.opensuse.org/SDB:KDE_repositories
"kcmshell5 kwindecoration" - it uses "new" breeze (ie. "real" breeze) when the supportInformation output says "breeze" The SuSE repo does not seem to provide libkdecoration2, so it won't provide the "new" breeze deco plugin either :-(
When I bring kcmshell5 kwindecoration up, all I see is breeze oxygen and plastik. Is aurorae not being an option there a bug?
Aurorae is an engine, it doesn't show up in the list but "themes" using it (in this case breeze) do. Plastik uses QML as well, so please try oxygen to ensure this is not just "the" qml ./. opengl issue.
It is still happening when oxygen is being used from the kcmshell5 kwindecoration setting window
can you check dmesg | grep -iE '(nvidia|nvrm)' after such incident? (and post it here ;-)
$ dmesg | grep -iE '(nvidia|nvrm)' [ 7.902852] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input18 [ 7.902924] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input19 [ 7.902993] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20 [ 8.238225] nvidia: module license 'NVIDIA' taints kernel. [ 8.244694] [drm] Initialized nvidia-drm 0.0.0 20130102 for 0000:01:00.0 on minor 0 [ 8.244709] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 343.22 Thu Sep 11 16:27:43 PDT 2014 [ 20.670705] nvidia 0000:01:00.0: irq 47 for MSI/MSI-X [ 21.278947] NVRM: Your system is not currently configured to drive a VGA console [ 21.278963] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 21.278965] NVRM: requires the use of a text-mode VGA console. Use of other console [ 21.278966] NVRM: drivers including, but not limited to, vesafb, may result in [ 21.278968] NVRM: corruption and stability problems, and is not supported. [ 61.451297] nvidia 0000:01:00.0: irq 47 for MSI/MSI-X [ 83.020138] nvidia 0000:01:00.0: irq 47 for MSI/MSI-X
That was when it happened with the main window of audacious. It doesn't seem to be a total freeze all the time, but it sometimes only slows down. So when it is playing music, the 'spectrum analyzer' updates about one frame per second. Other times the window stops updating entirely. Whenever I minimize it and restore it, the window updates to the current time of whatever track it is playing.
[ 21.278947] NVRM: Your system is not currently configured to drive a VGA console [ 21.278963] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 21.278965] NVRM: requires the use of a text-mode VGA console. Use of other console [ 21.278966] NVRM: drivers including, but not limited to, vesafb, may result in [ 21.278968] NVRM: corruption and stability problems, and is not supported. Ok, let's please first rule this out to be the cause - the setup is simply not supported by the nvidia blob and may cause (really) random problems. See eg. https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer on how to fix this.
Hey, I can confirm this bug. It happens a lot on my system, especially when using Google Chrome, browser window content freezes or sometime just lags. Minimizing/Maximizing seems to work as a temporary workaround. Trick with KWIN_USE_BUFFER_AGE=0 doesn't help. Basic system info: I'm using __GL_YIELD="USLEEP" to fix tearing. Fedora 21, kwin 5.2.2, breeze decoration. Nvidia 340.76
Noticed I also had Nvidia VGA console warning (booting via kernel efistub) unfortunately booting with text condole (via grub2) does not solve the problem, so this warning is irrelevant here :/ Does anyone have any debugging tips that could help narrow down this bug? Because I've a feeling that attaching gdb to the running kwin won't help much...
Nvidia 346.59 I experience similar problems with Chromium. In my case I think the "system" doesn't freeze ...it's that the window doesn't refresh. When it does happen (randomly, but quite frequently), clicking on something that should change the display apparently has no effect. However, then hitting the "minimise" button, followed by maximising the window removes the freeze condition and presents the display that was originally expected. It seems to happen more often when working in a maximised Chromium window, although I think I have seen it when working in a Chromium window sized less than max.
I have exactly the same problem only with chrome and an nvidia graphics card. Chrome works fine, i.e. scroll wheel on the tabs changes the window title accordingly, but the display of the window freezes regularly for some seconds. The freezing stops on disabling compositing with Alt-Shift-F12.
Some minutes ago, the system was thrashing for a long time because of extreme memory pressure and chrome display froze even after the system recovered. Only Alt-Shift-F12 would restore normal display of the browser.
One more detail: menus triggered from the frozen window appear normally, even though the rest of the window is frozen.
(In reply to auxsvr from comment #18) > One more detail: menus triggered from the frozen window appear normally, popup menus are windows of their own. Since the client (process) isn't locked, they're expectably not affected by this, as it's either insufficient damage events (handling) or pixmap and texture getting out of sync. If you can also reproduce it with xrender compositing, it's not the latter, but other than this, we'll need a way to reproduce this, in order to check *what* fails (and then "why") Stupid question: does KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace & seem to prevent it?
No, KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace & doesn't prevent it.
Created attachment 93908 [details] Output of qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation I've been having the same issue for months now with a Radeon card. Seems like this issue has been happening with Intel and NVidia also... If there is any more information I can provide to help resolve this, please let me know. It's getting old the have to continue to hit ALT F2 multiple times to get a command prompt so I can enter: killall plasmashell ; plasmashell - This never occured with KDE4, only started with I upgraded to F22 which has Plasma5.
> killall plasmashell ; plasmashell this resolution does *not* fit this bug. apparently the plasmashell process stalls (gdb attach to it to see where and file a bug against plasmashell), but this bug is about redirected windows not updating (and resolved by restarting the compositor)
(In reply to Thomas Lübking from comment #22) > > killall plasmashell ; plasmashell > > this resolution does *not* fit this bug. > > apparently the plasmashell process stalls (gdb attach to it to see where and > file a bug against plasmashell), but this bug is about redirected windows > not updating (and resolved by restarting the compositor) Thanks... I'll file another bug
I'm seeing this quite often with mpv (when a video is drawn). It definitely happens when using xv, but I think also when using vdpau (but will try explicitely). I've also seen this happening when watching a video inside Firefox. IIRC, I've seen this with both EGL and GLX. Restarting kwin will fix it. Restarting the application will fix it as well. Will try the sync option. The video driver is radeonsi on a Kaveri. I'll attach the kwin support info file.
Created attachment 96535 [details] qdbus-qt5 org.kde.KWin /KWin org.kde.KWin.supportInformation
vdpau specific: does it a) start to update when you suspend the compositor b) still update when you resume the compositor afterwards?
(In reply to Thomas Lübking from comment #26) > vdpau specific: does it > a) start to update when you suspend the compositor > b) still update when you resume the compositor afterwards? I've tried to reproduce this with vdpau for approx. a week now and doesn't seem to happen, so I'm not sure anymore it is triggered with that.
(In reply to Thomas Lübking from comment #26) > vdpau specific: does it > a) start to update when you suspend the compositor > b) still update when you resume the compositor afterwards? Not sure if that matters, but for xv video output, both a) and b) can be answered with yes. Trying with vdpau again, now.
(In reply to Bernd Steinhauser from comment #28) > (In reply to Thomas Lübking from comment #26) > > vdpau specific: does it > > a) start to update when you suspend the compositor > > b) still update when you resume the compositor afterwards? > > Not sure if that matters, but for xv video output, both a) and b) can be > answered with yes. Trying with vdpau again, now. Ok, so I'm now pretty sure, that it doesn't with vdpau. Why? I had two mpv running, one with --vo=vdpau and one with --vo=xv. The latter is now frozen, the former is still running fine.
It seems the southern islands chips do Xv via GLAMOR, ie. OpenGL... http://xorg.freedesktop.org/wiki/RadeonFeature/ So this seems strictly related to redirected GL clients. Did you try downforcing buffer_age support? export KWIN_USE_BUFFER_AGE=0; kwin_x11 --replace & (I do not assume this to be the cause if it's related to some windows only) Can you please attach /var/log/Xorg.0.log and - if present - ~/.drirc?
I've had this issue a few years and it is still there. This is the only major annoyance I run into repeatedly with KDE, it happens on average ~2-3 times a week (while working full time). Mostly it happens to Firefox and VirtualBox. I've also seen it happen on Libreoffice, Audacious and Eclipse, but it can seemingly happen on any application in heavy use. It also happens to Plasma itself where the taskbar stops updating (opening/switching windows lags one window behind), hover will not redraw it but clicking on the taskbar will. I've had the problem happen on two different machines (both with nVidia graphics but it happens with both the proprietary driver and nouveau) from early versions of KF5 up until present Plasma 5.8.7, Frameworks 5.36.0, QT 5.6.1, Kernel 4.11.0-14. Arch Linux and Linux Mint 18.2. I currently runt compositing on OpenGL 3.1, but OpenGL 2.0 also had the problem. Others (#330424) report that Xrender is also affected. From my user perspective these are possible duplicates as they describe the same symptoms: https://bugs.kde.org/show_bug.cgi?id=330424 https://bugs.kde.org/show_bug.cgi?id=366651 https://bugs.kde.org/show_bug.cgi?id=353983 https://bugs.kde.org/show_bug.cgi?id=342500 https://bugs.kde.org/show_bug.cgi?id=343661 https://www.reddit.com/r/kde/comments/6ggjx8/windows_sometimes_stop_updating_content_kwin/ https://forum.kde.org/viewtopic.php?t=101313
I tried with latest neon, and again appears this issue. Tried everything. It is the compositor, because I removed it from the startup and used compton flawless. This is a major bug because a lot of tools become unusable. My latest discovery: the Android emulator. I tried: - All kwin enviroment variables suggested here. - Changin nvidia full composite and vsync - Disable all desktop effects - Tried opengl2, 3 and xrender - all options from the menu about screen painting - and a large etc I suggest to focus on this bug because turns KDE unusable for productivity in most cases. The only workaround worked is to use another compositor that actually works like compton. Kwin compositor is non usable. At least at my 4 computers, same problem on different configurations, different cards, different distros. Thank you in advance,
This issue with the compositor has been going on for YEARS! Is this beyond everyone's grasp? It would be most helpful and logical to get to the root of this problem. It can cause unrecoverable disk errors. I have had to re-install my OS several times directly as a result of this bug. I see people reporting this and being told to try changing the rendering backend, but that is not a solution. And then the issue is closed as if it is resolved. It has not been resolved. Please fix this MAJOR FLAW! A lot of blame is being laid on the intel driver...guess what? I don't have an intel anything in my desktop pc. It is all AMD.
> Please fix this MAJOR FLAW! It's pretty difficult to fix a bug if one can't reproduce it.
Created attachment 128976 [details] attachment-6273-0.html And it's impossible to report something that happens at random! On 6/1/20 3:18 AM, Vlad Zahorodnii wrote: > https://bugs.kde.org/show_bug.cgi?id=342326 > > --- Comment #35 from Vlad Zahorodnii <vlad.zahorodnii@kde.org> --- >> Please fix this MAJOR FLAW! > It's pretty difficult to fix a bug if one can't reproduce it. >
Can you still reproduce the issue with some more recent version of Plasma?
Version 5.18.7 still has an issue. After about 1-2 days following a reboot, portions of the screen stop being repainted. I can correct this by changing any of the Compositor settings. Lately, I have been checking and unchecking the "Allow applications to block compositing". This will fix only for an indeterminate time.
(In reply to cor from comment #38) > Version 5.18.7 still has an issue. Plasma 5.18 had it's latest and last point release with 5.18.8 on Tue 2021-10-19. [1] You should try to upgrade to something more recent, which is not EOL. The current version is 5.25. [1] https://community.kde.org/Schedules/Plasma_5
That's not a part of Kubuntu 20.04. I am an end user, not a developer or tester.
(In reply to cor from comment #40) > That's not a part of Kubuntu 20.04. I am an end user, not a developer or tester. I see, > Kubuntu 20.04 LTS will be supported for 3 years until April 2023. but I don't know how your distribution handles backporting of fixes in this case. Maybe someone else who had experienced this issue, can confirm that this bug persists on some recent release, so that it maybe can get fixed and backported?
Does KDE share with Ubuntu? Seems you should have directed this to the Kubuntu team. I am only reporting what I have encountered. And to tell you the truth, this is not working for me. I regret ever contacting bugs.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Created attachment 151483 [details] qdbus org.kde.KWin /KWin supportInformation > kwinsupportinfo.txt Throwing my hat in before this gets auto-closed to say I've also been experiencing this issue. Mostly with Chromium and Firefox, but I've seen it in other apps like System Monitor and even the taskbar once or twice. The window will stop repainting, and while it will respond to input it will only actually repaint if moved or resized. My current workaround is to simply close and reopen the window (minimizing and restoring doesn't work). Distro: Gentoo Kernel: 5.19.1-gentoo-x86_64 Graphics: GTX 1080Ti, nvidia-drivers 515.65.01 KDE: Plasma 5.25.4, Frameworks 5.97.0, Breeze Dark theme (if that matters) Often, the affected window is a browser window that contains media (i.e. a YouTube tab).
Seems like the question that put this bug into NEEDSINFO was "is this still happening on a more recent version of Plasma?" and I can say that the answer is yes (see my last post), so I'm gonna remove the NEEDSINFO as described by the bot. Unfortunately, while it does happen, pretty much daily (sometimes several times a day)... I haven't yet pinned down an actual reproducible case besides "just use the computer and wait for it".
This has been happening to me for several years, ever since I switched from Windows to Linux. It happened to me on Kubuntu 15.10, 16.04 and now 20.04. I think it can affect any application, it doesn't discriminate. A few years ago researching this issue I remember stumbling upon a suggestion that it was due to a conflict between the Qt framework and running Java applications, something about Java applications not invalidating some video-related caches and thus causes problems to prop-up elsewhere. I resolve this by opening the Compositor settings and then toggling a radio button off and then on again, just so that the Apply button becomes enabled and allows me to trigger something. Perhaps this restarts the compositor or perhaps it does something less destructive, I don't know, but this has been the workaround I have been using several times per week for several years. It takes me only 20 seconds each time, but those 20 seconds add-up and so does the frustration. Also I am using an nVidia card, and the issue occurred on two different cards, both brand new. I don't know how the internals work, but I would be very surprised if this issue turned-out to be hardware-related.
> I resolve this by opening the Compositor settings and then toggling a radio > button off and then on again, just so that the Apply button becomes enabled > and allows me to trigger something. Perhaps this restarts the compositor or > perhaps it does something less destructive, I don't know, but this has been > the workaround I have been using several times per week for several years. > It takes me only 20 seconds each time, but those 20 seconds add-up and so > does the frustration. This might help: pressing Alt-Shift-F12 twice does what you're doing but faster. It's the KWin shortcut for "Suspend compositing". > Also I am using an nVidia card, and the issue occurred on two different > cards, both brand new. I don't know how the internals work, but I would be > very surprised if this issue turned-out to be hardware-related. I have a dual GPU laptop, with a Radeon iGPU and an NVidia dGPU. I have been experiencing this exact same issue under X11 since I upgraded my KDE neon laptop to Plasma 5.27. Never happened under 5.26, and now it's happening almost every day. It seems to trigger after a long period of time on its own, without any user interaction. I can be away from my computer for awhile and come back and find that it appears to be unresponsive except for a movable cursor; the screen is on. Disabling the compositor with Shift+Alt+F12 is what gets my session usable again, but the Plasma panels are non-responsive though I see that plasmashell is still running with htop. I have to kill all the programs and reboot to get a usable desktop again. I've been trying to find a pattern for what causes it, and there is always at least one program that seems to be in an unresponsive state when the compositor stops working and needs to be forcibly killed. Correlation? I see that there are other mentions of this issue: https://bugs.kde.org/show_bug.cgi?id=366651 (ongoing from 2016-2021) https://bugs.kde.org/show_bug.cgi?id=342326 (ongoing from https://bugs.kde.org/show_bug.cgi?id=425557 (ongoing since 2020) https://www.reddit.com/r/kde/comments/6ggjx8/windows_sometimes_stop_updating_content_kwin/ I was thinking the issue was some byproduct of the OpenGL drivers, so I installed the Obiaf PPA to get the latest Mesa, but there was no change. I saw one post from 2016 (https://bugs.kde.org/show_bug.cgi?id=366651#c6) where Martin Flöser highlighted that the org.kde.kwin.aurorae was suspect and suggested to "Please try to use the breeze window decoration." I found that I had been using Aurorae, so I just now switched to Breeze for window decorations. We'll see if this makes a difference. I have lost so much work due to this bug, so I am fully committed to assisting to get it fixed in any way I can. I've created a set of information about KWin, my graphics drivers and my system here: https://invent.kde.org/-/snippets/2620 Please tell me what else you need to help nail this down.
*** Bug 366651 has been marked as a duplicate of this bug. ***
*** Bug 425557 has been marked as a duplicate of this bug. ***
Thanks for those references. These are old bugs, but let's see what we can do with your report. I'll mark those older ones as duplicates of this one for now and hand it off the the Real Devs™.