I am planning to open a bug report on bugs.kde.org for this, but I wanted to ask here first if this is a known regression.
I’m experiencing a severe performance regression on my external monitor under KDE Plasma Wayland. This setup worked flawlessly back in January, but an update around late March/April completely broke the fluidity of the external HDMI output.
System Specifications:
Laptop: HP Victus 16-e1xxx
CPU / iGPU: AMD Ryzen 5 6600H (Radeon 660M)
dGPU: NVIDIA GeForce RTX 3050 Ti Laptop (Proprietary drivers)
OS: Arch Linux (Fully up to date)
DE: KDE Plasma 6 (Wayland)
Monitors: Internal laptop screen (144Hz) + External GWD ARZOPA (60Hz) (also with other monitor)
The Issue: Moving any window (even simple apps like Dolphin or a terminal) on the external HDMI monitor is extremely laggy/choppy. The HDMI port is hardwired to the NVIDIA dGPU, while KWin renders the desktop on the AMD iGPU. When observing nvtop, moving a single window on the external screen causes the NVIDIA GPU usage to spike to ~40%. It seems like the Cross-GPU buffer copy via Wayland/DRM is struggling heavily.
Note: While the USB-C port (hardwired to the AMD iGPU) outputs a perfectly smooth image, using it as a permanent workaround is not ideal for my setup. The core issue is that the HDMI output used to work flawlessly earlier this year, so I am looking to fix this regression rather than abandoning the port entirely.
Troubleshooting already done (None worked):
Lowered the internal screen refresh rate from 144Hz to 60Hz to match the external monitor (Testing for VSync/clock sync issues) → No difference.
Added KWIN_DRM_USE_MODIFIERS=0 to /etc/environment → Made the external screen completely unusable/worse.
Disabled NVIDIA GSP Firmware (nvidia.NVreg_EnableGpuFirmware=0 in GRUB) → No difference.
Forced CPU to performance mode via auto-cpufreq to rule out PCIe ASPM power-saving drops → No difference.
Verified apps are running natively on Wayland (e.g., Firefox Window Protocol: wayland in about:support), ruling out Xwayland overhead.
Since this was perfectly smooth in January, it feels like a regression in KWin 6, Mesa, or recent NVIDIA drivers regarding hybrid graphic buffer sharing.
Has anyone encountered this specific regression recently, or is there a known bug tracker/patch for this issue in Plasma 6?
I am currently using the 595.58.03 branch. Also, an important detail: I am using the open-source kernel modules (nvidia-open-dkms), not the proprietary ones.
Here is the output of my nvidia-smi:
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.58.03 Driver Version: 595.58.03 CUDA Version: 13.2 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 3050 ... Off | 00000000:01:00.0 Off | N/A |
| N/A 36C P3 8W / 30W | 23MiB / 4096MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 742 G /usr/lib/Xorg 4MiB |
+-----------------------------------------------------------------------------------------+
My Arch Linux installation is fairly recent (late December 2025). Checking my pacman.log, here is the exact upgrade path I followed:
Jan 13: Upgraded to 590.48.01-2(HDMI output was perfectly smooth here)
Feb 13: Upgraded to 590.48.01-4
Apr 05: Upgraded to 595.58.03-1
Apr 18: Upgraded to 595.58.03-2(Current version)
The extreme lag on the external monitor started to happen around mid-February to early March. So the regression was likely introduced either during the lifecycle of the 590.48.01 driver branch, or triggered by a KWin/Wayland update that dropped during that exact same timeframe.
Just a quick follow-up: as there haven’t been any suggestions and the issue persists despite the detailed troubleshooting above, is there anyone here with a lead?
If not, I will proceed to open a formal bug report on bugs.kde.org under the KWin component, as this clearly looks like a regression in how the cross-GPU buffer copy is handled between the AMD iGPU and the NVIDIA GPU on Wayland.
If the behavior is not affected by different KWin version, i.e Plasma version, but only the nvidia driver changed, that’s a scientific demonstration the issue is in the Nvidia driver, and you might want to nvidia forum
But that would be true only if the test runs are very very similar and many things can affect this.
You are using an APU+GPU so that might be an important factor, the wrong GPU might be used for the compositing adding copying between the GPU rendering and the GPU outputting to the screen.
You can try to force some applications on a specific GPU.
IIUC this only happens when transferring a window to another screen, but there is no issue once the window is fully on the other screen. So while it looks bad, this shouldn’t affect much you laptop usage and there is a shortcut to switch an application to another screen IIRC to workaround this..
And That seems logical: if both GPU must output the same application because they use manage each their screen and the window is partly on both screen, the application rendering must be copied over to both GPU, and that’s a typical performance issue. Still as long as the application does not update its rendering (or not too often) this wouldn’t be a big issue, but I see your internal screen is 144Hz, whereas the external screen is 60Hz. The discrepancies here might cause issues.
You can try to look at kwin logs to see if it tells something relevant which is likely.
Hi @meven, thank you for stepping in and providing these insights!
I couldn’t really isolate the problem to KWin, NVIDIA, or Wayland at first, but your comment made me dig deeper into my pacman.log to check what exactly changed during my regression window (mid-February to early March).
It turns out, you are right to ask about the KWin version, because my NVIDIA driver did not change during that time (it stayed on 590.48.01 from Jan 13 to Apr 05). However, there was a major KWin (KDE 6.6) release right in the middle of that window:
The jump to KWin 6.6.0 on February 21 aligns perfectly with when the issue started. This makes me suspect the regression might indeed be tied to how KWin 6.6 handles the cross-GPU buffer copy between the AMD iGPU and NVIDIA GPU, rather than a pure NVIDIA driver bug.
To clarify one detail about the behavior (my apologies if my previous posts were unclear): the lag doesn’t only happen when transferring a window. Even when the window is fully on the external screen, the whole secondary monitor remains extremely laggy/stuttery. The 144Hz (internal) vs 60Hz (external) discrepancy is definitely a factor, but this exact APU+GPU hardware setup was buttery smooth back in January on KWin 6.5.
I would love to look at the KWin logs to find something relevant and pinpoint the issue. What is the best command to get the specific output you need while I reproduce the stuttering? Would journalctl --user -u plasma-kwin_wayland -f do the trick?
That should be it.
You can enable more debugging output: KWin/Debugging - KDE Community Wiki if needed, but the default log level should be sufficient already.
Did you update to a more recent Plasma version since 6.6.1 ? 6.6.4 is the latest.
Important regressions are often fixed in subsequent releases.
Once you have tested with the latest version and got the logs, then you can report those informations to a bug for kwin on http://bugs.kde.org/
There might be some workaround not sure.
Thanks for confirming the command and for linking that Merge Request.
To answer your question: yes, I am already on the latest KWin 6.6.4-1 (updated on April 14th), and unfortunately, the regression is still fully present in this release.
Just to reiterate, I have also already tested multiple workarounds over the past few weeks (forcing specific environment variables, testing different KWin rules, etc.), but nothing mitigated the stuttering on the external screen.
As suggested, I ran journalctl --user -u plasma-kwin_wayland -f while actively reproducing the lag on the secondary monitor.
Here is the output when the external screen is to connect via HDMI (thousand of lines in few seconds):
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:06 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>.
mai 07 16:29:07 AlexisVictusL kwin_wayland[1450]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
When the external screen is to connect via USB-C → USB-C It doesn’t lag and there is no output for the command.
Could you let me know if anything stands out in these logs? If this confirms the issue or if you need this tracked officially, I will go ahead and open the formal bug report on bugs.kde.org with all this data. Thanks again for your time!
I checked the bug list you linked. While the GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT error matches perfectly, I noticed that the specific contexts in those four reports (hardware configurations, exact triggers) don’t entirely match my situation (the AMD iGPU + NVIDIA dGPU setup, and the fact that the stuttering on the external screen appeared specifically as a regression starting with KWin 6.6).
Before I potentially create a duplicate, what would you recommend?
Should I still go ahead and open a new, dedicated bug report to provide my exact regression timeline, hardware details, and these specific logs? Or is the underlying multi-GPU buffer copying issue already well-understood by the team and actively being fixed through those existing tickets and the Merge Request you mentioned earlier?
I’m ready to file the report right away if it helps
Bug #517987 looks exactly like my issue, although I am using the nvidia-open-dkms driver rather than the standard proprietary one.
Plasma 6.6.5 hasn’t hit the Arch Linux repos just yet. I will wait for the update to drop, test the HDMI output, and if it solves the problem, I will report back here and we can close this thread.