https://bugs.kde.org/show_bug.cgi?id=521668
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
