DESCRIPTION kwin on 6.7 crashes when a DisplayLink display is connected. It keeps crashing on relaunch as long as the display stays connected, and stops crashing as soon as the display is unplugged. Updating from fedora-44-displaylink-1.14.15-1.github_evdi.x86_64.rpm to fedora-44-displaylink-1.14.16-1.github_evdi.x86_64.rpm made no difference. STEPS TO REPRODUCE 1. Update Plasma from 6.6 to 6.7 on Fedora 2. Attach DisplayLink display 3. Crash 4. ??? 5. Profit! OBSERVED RESULT Crash EXPECTED RESULT Normal operation SOFTWARE/OS VERSIONS Operating System (available in the Info Center app, or by running `kinfo` in a terminal window): Fedora 44, kernel 7.0.12-201.fc44.x86_64 KDE Plasma Version: 6.7.0 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 ADDITIONAL INFORMATION Dropping back to Plasma 6.6 via `sudo dnf downgrade plasma-desktop`, followed by a reboot, returned the box to working condition. Bug 520361 may be related.
Created attachment 193313 [details] Backtrace
Also hitting the similar issue on Plasma 6.7.0 (Arch Linux, kernel 7.0.12-arch1-1). In my case the dominant symptom is persistent flicker on the DisplayLink outputs rather than a hard crash, which I think points at the same multi-GPU copy path. Setup: - Primary render GPU: Intel (xe), driving one native DisplayPort monitor (2560x1600@144) -- this output is never affected. - Two external DVI monitors via a DisplayLink dock = evdi 1.14.16 virtual devices (secondary GPU). The evdi outputs run ABGR8888. - kwin_wayland 6.7.0, Wayland session. Symptoms: persistent flicker on the two DisplayLink outputs, plus a single kwin_wayland SIGSEGV inside libgallium (Mesa) at session startup that self-recovered. Downgrading the whole Plasma stack to 6.6.5 (keeping KF 6.27 + Qt 6.11.1) fully fixes both the flicker and the crash. Env-var test matrix (with the usual DisplayLink workarounds already set: KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1, KWIN_DRM_USE_MODIFIERS=0, KWIN_DRM_NO_DIRECT_SCANOUT=1, KWIN_FORCE_SW_CURSOR=1, and KWIN_DRM_DEVICES pinned Intel-first): - KWIN_DRM_FORCE_GL_FINISH_MGPU_COPY=1: flicker disappears completely, BUT the per-frame glFinish stalls the shared render loop and drags the ENTIRE desktop -- including the native 144Hz Intel monitor -- down to ~30fps. - KWIN_DRM_NO_AMS=1 (and plain atomic without the glFinish): smooth/full refresh, but the flicker returns. - Dropping the DisplayLink outputs from 75Hz to 60Hz: no effect on the flicker. The fact that only a full pipeline drain (glFinish) immediately before the cross-GPU copy eliminates the tearing suggests the new GPU-based multi-GPU copy path from !9236 ("backends/drm: don't use a software renderer for multi GPU copies", commit 0d6b757c, bug 520361) is letting the secondary/DisplayLink GPU scan out before the copy has completed -- i.e. a missing fence/sync between the copy and the secondary-GPU presentation. That change fixed the 520361 crash but looks like it traded it for a frame-sync regression on the DisplayLink scanout.
with display link dock already attached during boot, the system does not reach the login screen.
Date: 2026-06-18 / 2026-06-19 System: Arch Linux, kernel 7.0.12-arch1-1, KDE Plasma (Wayland), AMD GPU (amdgpu), Dell D6000 USB dock (DisplayLink, USB VID 17e9), displaylink 6.2-1, evdi-dkms 1.14.15-1 --- Symptom Following a routine system update that brought in KWin 6.7.0-1, the Dell D6000 dock became non-functional under Plasma Wayland. At login, kwin_wayland entered a crash loop: 10+ restarts over approximately 28 seconds, each terminated by a SIGSEGV in the llvmpipe-3 thread (segfault at c30). Once the crash loop subsided, the dock monitors displayed the SDDM login screen rather than the Plasma desktop. kscreen-doctor -o showed only the internal display (eDP-1); the dock outputs were absent. --- Diagnosis Journal analysis (journalctl -b) confirmed repeated kwin_wayland exits with signal 11, followed by SDDM spawning a new Xorg process (/usr/bin/Xorg :1 -seat seat0 vt2) on each restart. By the time KWin stopped crashing, SDDM's Xorg held DRM master on the evdi devices, so KWin could no longer open them — hence the dock showing the SDDM session instead of Plasma. Root cause: KWin 6.7.0 GpuManager regression KWin 6.7.0 introduced a new GpuManager class (src/core/gpumanager.cpp) that separates GPU roles into "render devices" (cards with renderD* DRM nodes) and "display devices" (KMS/DRM outputs). When pairing a display device with a render device, GpuManager::findCompatibleRenderDevice() searches for a render device on the same bus. evdi (the DisplayLink kernel module) is a DRM_BUS_PLATFORM device and has no renderD* node. The AMD GPU is DRM_BUS_PCI. Because no platform-bus render device exists to pair with evdi, findCompatibleRenderDevice() returns nullptr. This causes the evdi DrmGpu's renderDevice() to be null, which triggers KWin to fall back to software rendering via llvmpipe for the DisplayLink outputs. llvmpipe then crashes during pipeline initialization for those outputs. KWin 6.6.x does not have GpuManager; the regression is entirely contained within 6.7.0. What was ruled out: - options evdi initial_device_count=4 in /etc/modprobe.d/evdi.conf — ensures evdi DRM nodes exist at boot but does not fix the null render device pairing; crash persisted. - SDDM/kwayland configuration — the SDDM-on-dock-displays symptom was a secondary consequence of the crash loop, not an independent cause. --- Fix Downgraded kwin from 6.7.0-1 to 6.6.5-4 using the Arch Linux package archive: `sudo pacman -U https://archive.archlinux.org/packages/k/kwin/kwin-6.6.5-4-x86_64.pkg.tar.zst` Only kwin itself required downgrading. KWin 6.6.5 links against libkdecorations3.so.6 and libKF6*.so.6 sonames that are unchanged in the 6.7.x Plasma packages, so the rest of the Plasma suite remained at 6.7.x without ABI conflict. To prevent the package manager from silently re-upgrading kwin on the next pacman -Syu, kwin was added to IgnorePkg in /etc/pacman.conf: IgnorePkg = kwin After relog, kwin_wayland --version confirmed 6.6.5. All dock displays came up correctly under Plasma Wayland. --- Resolution System is stable with kwin 6.6.5-4 pinned. The upstream bug is tracked as KDE Bugzilla #521668 ("kwin_wayland SIGSEGV when DisplayLink display is connected"). IgnorePkg should be cleared and kwin upgraded once that bug is resolved in a future release.
Hi, I'm the guy who made the other bug report that was marked as fixed (https://bugs.kde.org/show_bug.cgi?id=520361). It was fixed for me back then, but I can confirm that the problem came back. When I turn on my display link dock, KWin crashes repeatedly. I will try to get another KWin GDB backtrace by SSHing into my computer again.
*** Bug 520361 has been marked as a duplicate of this bug. ***
I have similar problem with SDDM in Wayland mode with `CompositorCommand=kwin_wayland --drm --no-global-shortcuts --no-lockscreen`. I have two screens and two GPUs, internal screen is through Intel GPU, external is NVidia. SDDM+kwin crashes after less then second, but Plasma session runs, but with very low animation speed on external screen. For some reason for SDDM kwin_wayland crashes with kinda similar backtrace (at least KWin::Compositor::setupLayers is there): (sorry its mangled, I've downgraded KWin and now GDB doesn't unmangle function names properly) ``` #0 0x00007f9f0509d87c __pthread_kill_implementation (libc.so.6 + 0x9d87c) #1 0x00007f9f050424c6 raise (libc.so.6 + 0x424c6) #2 0x00007f9f0912ab35 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x8b35) #3 0x00007f9f05042620 __restore_rt (libc.so.6 + 0x42620) #4 0x00007f9f08939b14 _ZNK4KWin12RenderDevice9drmDeviceEv (libkwin.so.6 + 0x339b14) #5 0x00007f9f08c4079e n/a (libkwin.so.6 + 0x64079e) #6 0x00007f9f088ec5cd _ZN4KWin10Compositor11setupLayersEPNS_9SceneViewEPNS_13LogicalOutputEPNS_13BackendOutputERK5QListIPNS_11OutputLayerEERKSt13unordered_mapIS9_PNS_4ItemESt4hashIS9_ESt8equal_toIS9_ESaISt4pairIKS9_SF_EEERKSt10shared_ptrINS_11OutputFrameEENS0_9SetupTypeERSt13unordered_setIS9_SH_SJ_SaIS9_EE (libkwin.so.6 + 0x2ec5cd) #7 0x00007f9f088f322b _ZN4KWin10Compositor9compositeEPNS_10RenderLoopE (libkwin.so.6 + 0x2f322b) #8 0x00007f9f05a4632e n/a (libQt6Core.so.6 + 0x24632e) #9 0x00007f9f0894624b _ZN4KWin10RenderLoop14frameRequestedEPS0_ (libkwin.so.6 + 0x34624b) #10 0x00007f9f05a39ed6 _ZN7QObject5eventEP6QEvent (libQt6Core.so.6 + 0x239ed6) #11 0x00007f9f06be82d8 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt6Widgets.so.6 + 0x1e82d8) #12 0x00007f9f059db088 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt6Core.so.6 + 0x1db088) #13 0x00007f9f05b8fa3c _ZN14QTimerInfoList14activateTimersEv (libQt6Core.so.6 + 0x38fa3c) #14 0x00007f9f05b99014 _ZN20QEventDispatcherUNIX13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x399014) #15 0x00007f9f06796041 _ZN23QUnixEventDispatcherQPA13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Gui.so.6 + 0x796041) #16 0x00007f9f059e9a33 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x1e9a33) #17 0x00007f9f059df083 _ZN16QCoreApplication4execEv (libQt6Core.so.6 + 0x1df083) #18 0x0000561d971869cb n/a (kwin_wayland + 0x5e9cb) #19 0x00007f9f0502b33e __libc_start_call_main (libc.so.6 + 0x2b33e) #20 0x00007f9f0502b46b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b46b) #21 0x0000561d9718b3a5 n/a (kwin_wayland + 0x633a5) ``` Is this the same bug, or should I create new bugreport? Should I create bugreport for slow animation on external screen?
(In reply to Mykola Krachkovsky from comment #7) > I have similar problem with SDDM in Wayland mode Your backtrace is different than the one from the original reporter, so you have a different crash. Yours looks like the one in bug 521898, which you can cc yourself on.
(In reply to matthijsbulsink@hotmail.com from comment #6) > *** Bug 520361 has been marked as a duplicate of this bug. *** I don't think it's correct to mark my bug as a duplicate because mine was actually fixed before. This is a new bug.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9441
Git commit 8ed0ac9f0f392cb092bebec0ce715ed98a7644a7 by Xaver Hugl. Committed on 22/06/2026 at 12:37. Pushed by zamundaaa into branch 'master'. opengl/egldisplay: fix the check for EGL_EXT_device_query It's a client extension, not a display extension, so it has to be queried in a different way. M +2 -1 src/opengl/egldisplay.cpp M +1 -0 src/opengl/egldisplay.h https://invent.kde.org/plasma/kwin/-/commit/8ed0ac9f0f392cb092bebec0ce715ed98a7644a7
Git commit fa14e1d7b4f78a528336db58f76e52f94d62005a by Xaver Hugl. Committed on 22/06/2026 at 20:36. Pushed by zamundaaa into branch 'Plasma/6.7'. opengl/egldisplay: fix the check for EGL_EXT_device_query It's a client extension, not a display extension, so it has to be queried in a different way. (cherry picked from commit 8ed0ac9f0f392cb092bebec0ce715ed98a7644a7) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +2 -1 src/opengl/egldisplay.cpp M +1 -0 src/opengl/egldisplay.h https://invent.kde.org/plasma/kwin/-/commit/fa14e1d7b4f78a528336db58f76e52f94d62005a
Is this confirmed as fixed in 6.7.1? It's not marked as such, but I'm seeing discussion that it has been.
Looking at the linked commit in the bug report, tags containing this commit include 6.7.1 and 6.7.2.
You're right! I had only the first commit open and it had a failing pipeline and no tags. I can confirm it was fixed in 6.7.1. Thank you!