Qt/KDE windows not setting _KDE_NET_WM_BLUR_BEHIND_REGION atom — transparent windows with no blur on Plasma 6 X11, Debian Trixie, NVIDIA 580

Help
,
1

System:

  • Debian 13 Trixie, upgraded from Bookworm March 2026

  • KDE Plasma 6.3.6, KWin 6.3.6, Qt 6.8.2

  • NVIDIA RTX 4060, driver 580.126.20 (CUDA repo), X11/GLX

  • lightdm login manager

Problem: After upgrading from NVIDIA driver 580 to 595.58.03 and reverting back to 580.126.20, Qt/KDE application windows (Konsole, Kate context menus, Dolphin context menus, system tray popups) are transparent — showing desktop/windows behind them with no blur fill. GTK apps (Firefox, Thunar) are unaffected.

KWin compositing is active, OpenGL/GLX confirmed working, blur effect is loaded and listed as active in supportInformation. However, xprop on any KDE window returns no _KDE_NET_WM_BLUR_BEHIND_REGION atom — windows are not requesting blur from KWin at all.

What has been tried:

  • QT_QPA_PLATFORMTHEME=kde confirmed set and loading KDEPlasmaPlatformTheme6.so

  • widgetStyle=Breeze set in kdeglobals

  • Plasma style set to both breeze and breeze-dark — no change

  • kwinrc deleted and regenerated clean

  • kwriteconfig6 --file kwinrc --group Plugins --key blurEnabled true + reconfigure

  • Reinstalled: libkf6windowsystem6, plasma-desktoptheme, plasma-integration, libplasma6, plasma-workspace, kwin-x11, and all plasma/kwin/libkf6 packages

  • Logout and login after each attempt

Question: What controls whether Qt/KDE windows set the _KDE_NET_WM_BLUR_BEHIND_REGION X atom? What package or library is responsible, and how can it be fixed without a full reinstall?

———————
i did some more pocking and proding and found out more things

The _KDE_NET_WM_BLUR_BEHIND_REGION atom was never being set (original report)

  1. Root cause found: X,Org libglx.so was loading before NVIDIA’s GLX module, causing degraded context
  2. Fixed via dpkg-divert — GLX registration now correct per Xorg log
  3. But loadEffect blur still returns false despite GL_ARB_framebuffer_object present and GLX correct
  4. Loaded Effects shows only screenshot and outputlocator
2

cant figure out how to edit this into the above post.
one last thing i found but i am completly out of ideas now

when _KDE_NET_WM_BLUR_BEHIND_REGION is set manually via xprop, KWin does respond — the window becomes opaque white rather than showing the correct blurred background. This suggests the blur shader is initialising and running but rendering incorrectly, rather than not loading at all.

One additional finding I should have mentioned: GTK applications display normally — this problem only affects KDE/Qt applications.

3

continued testing and i still cant figure out how to edit a post more then once.

if Konsole is launched while the compositor is off, and the compositor is then turned back on, that Konsole window remains visible. However if Konsole is launched while the compositor is on, turning the compositor off makes it visible, but turning it back on makes it transparent again.

4

Further investigation update (Apr 7 2026):
Confirmed today that the _KDE_NET_WM_BLUR_BEHIND_REGION atom IS being set on affected windows — it’s present but empty, which per KDE documentation means “blur the entire window.” So the atom side is correct.
Additional diagnostic results:

dpkg -V on all OpenGL libraries (amd64 and i386): no file corruption
nvidia-settings -q OpenGLVersion: reports 4.6.0 NVIDIA 580.126.20 correctly via NV-CONTROL
glxinfo: reports OpenGL 4.6, RTX 4060, direct rendering, GLX 1.4 — standard chain healthy
Raw GLX context probe (C program creating a GLX context directly): reports identical results
Picom with --backend glx: fails identically to KWin compositor — confirms breakage is in the OpenGL path, not KWin-specific
Picom with --backend xrender: works perfectly — compositor functional via non-OpenGL path
KWin debug log (QT_LOGGING_RULES=“kwin_*.debug=true”): shows “OpenGL compositing successfully initialized” and “Successfully loaded plugin effect: blur” — no errors at load time
qdbus6 supportInformation: still reports GPU class Unknown, OpenGL 3.1, OpenGL 2 Shaders despite 4.6 context confirmed externally

The pattern: everything outside KWin’s internal GL capability detection sees a correct 4.6 context. KWin internally reports 3.1 and GPU class Unknown. Picom’s GLX backend fails the same way. The breakage is in how OpenGL capabilities are being reported to compositing applications specifically, not in the driver or GLX chain itself.
The _KDE_NET_WM_BLUR_BEHIND_REGION atom is set, blur effect loads, but KWin’s internal GL version assessment causes it to skip the blur render pass at runtime.