https://bugs.kde.org/show_bug.cgi?id=527328
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] --- Comment on bug 527328 — Screen goes black/flickers on mouse movement =========================================================== CONFIRMATION =========================================================== This bug reproduces reliably on my machine. I am adding a complete reproduction case and a working workaround, since the existing report is currently UNCONFIRMED with no data attached. Pattern across all affected reports: nouveau on older NVIDIA hardware. A machine with the proprietary nvidia driver and the same KWin/Mesa versions is unaffected. =========================================================== SYSTEM =========================================================== Distro: EndeavourOS (Arch Linux base) GPU: NVIDIA GM107 [GeForce GTX 750], 10de:1381 (Maxwell) Driver: nouveau (in-kernel), no proprietary driver Mesa: 26.2.5-arch1.1, renderer NV117, GL 4.6 compat / 4.3 Kernel: 7.2.11.arch1-1 KWin: 6.8.0-1 Plasma: plasma-workspace / plasma-desktop 6.8.0-1 libdrm: 2.4.134-1 Qt: 6.12.0-3 Wayland: XWayland 24.1.14 for legacy apps Display: 3 monitors, 4480x1344 total, all at 60 Hz - Philips PHL 246V5 1920x1080@60 DVI-I-1 (center) - LG GoldStar L1720P 1280x1024@60 DVI-D-1 (right) - Samsung SyncMaster 1280x1024@60 HDMI-A-2 (left) Note: three monitors at *identical* refresh rates. The original mismatched-rate setup (75/60 Hz) was NOT the cause — the problem persisted after aligning all outputs to 60 Hz. =========================================================== SYMPTOMS =========================================================== 1. Screen flickers and/or goes fully black when the pointer moves. 2. Output-specific behaviour, which is the most diagnostic part: * An output under the pointer keeps rendering normally. * Outputs WITHOUT the pointer go completely black (not dimmed, not standby — a black framebuffer). * Moving the pointer onto a black output immediately restores it. * Dragging a window repaints everything, and all outputs are fine for as long as the drag continues. * Opening the start menu or switching windows with the keyboard also restores all outputs until the next pointer movement. 3. A VTY without a compositor is completely unaffected. 4. sway + wlroots on the same kernel and the same DRM/nouveau stack is completely unaffected. This isolates the fault to KWin. 5. No compositor crash, no restart loop, no "GPU has hung". =========================================================== WORKAROUND THAT RESOLVES IT =========================================================== ~/.config/environment.d/99-kwin-flicker.conf: KWIN_USE_BUFFER_AGE=0 KWIN_DRM_FORCE_GL_FINISH_PRESENT=1 KWIN_FORCE_SW_CURSOR=1 ~/.config/kwinrc: [Plugins] shakecursorEnabled=false With this configuration: * flicker in the Plasma session: GONE * blacking-out of non-pointer outputs: GONE * applies across re-login and reboot Delivered via ~/.config/environment.d so that the variables are present in the actual kwin_wayland environ — verified via /proc/<pid>/environ. Note that `kwin_wayland --replace` does NOT propagate environment variables in this build; they must come from systemd's environment. Note on KWIN_FORCE_SW_CURSOR: each variable fixes a different part of the symptom. USE_BUFFER_AGE and FORCE_GL_FINISH_PRESENT together remove the flicker; FORCE_SW_CURSOR is additionally required, otherwise flicker returns. FORCE_SW_CURSOR alone is not sufficient. Note on ShakeCursorEffect: its metadata in /usr/share/kwin/builtin-effects/shakecursor.json declares "EnabledByDefault": true, so it is active out of the box. =========================================================== WHAT WAS RULED OUT =========================================================== * Mismatched refresh rates — aligned all outputs to 60 Hz, unchanged * Multi-monitor — still reproduces with a single monitor * Window decorations, blur, translucency — disabled, unchanged * KWin "ShakeCursorEffect" — disabled, verified via D-Bus org.kde.kWin /Effects isEffectLoaded(shakecursor) == false; still reproduced * KWIN_DRM_NO_DIRECT_SCANOUT — no effect * KWIN_DRM_DISABLE_TRIPLE_BUFFERING — no effect * KWIN_DRM_NO_AMS — makes the flicker strictly worse * Kernel 7.2.10 -> 7.2.11 — no change * Keyboard layout / accessibility features other than shake cursor Kernel log during the blackouts contains NOTHING. No page-flip timeouts, no FIFO stalls, no DRM errors at runtime. Only a single nouveau ... bus: MMIO read of 00000000 FAULT ... [ PRIVRING ] at nouveau init, before the session starts. =========================================================== RESIDUAL DEFECT =========================================================== The workaround is not a complete fix. One blink of all outputs remains, occurring exactly once when a window is hidden, restored or closed — i.e. on surface creation/destruction. It is a single frame of the order of tens of milliseconds and does not affect usability, but it indicates the underlying page-flip weakness is mitigated rather than corrected. I suspect KWIN_DRM_FORCE_GL_FINISH_PRESENT may be exposing an intermediate frame during buffer reallocation on surface create/destroy, but I did not remove the variable to test this, since it would risk reintroducing the constant flicker. Flagging it as a possible lead for anyone investigating. =========================================================== DIVERGENCE IN THE LOGIN SCREEN =========================================================== Worth recording, as it may narrow down the real cause. plasmalogin (plasma-login-manager 6.8.0-1) is affected as well, even though it is a separate KWin instance. I attempted to apply the same configuration to it and got a result that looks contradictory: * The three KWIN_* variables DO reach the greeter KWin (verified in /proc/<pid>/environ) * plasmalogin runs as root with no HOME and no XDG_CONFIG_HOME, but the greeter's KWin process has HOME=<user home> — so it reads the same ~/.config/kwinrc, with shakecursorEnabled=false * An XDG_CONFIG_HOME set via a systemd drop-in for plasmalogin.service does NOT reach the process, so plasmalogin appears to filter parts of the environment So the greeter ends up with a configuration equivalent to the working Plasma session, and it still flickers. This suggests the login screen may be failing for a related but distinct reason — possibly in how plasmalogin starts the compositor rather than in KWin's rendering path itself. (For reference, the other reporters on this bug state that their login screen works normally and only the session is affected — the opposite split from mine.) =========================================================== HARDWARE / DRIVER NOTE =========================================================== Nouveau appears to be the common factor across all reports so far (GTX 750 / Maxwell, 410M / GF119M, GT 520 / GF119, GT 710 / GK208B), while systems on the proprietary nvidia driver are unaffected. Every affected GPU is an older NVIDIA generation without the proprietary driver in use. =========================================================== REQUEST =========================================================== Could this be assigned/confirmed? The suggested next diagnostic step, in my view, is whether the fault is in KWin's atomic-modesetting page-flip path when only a subset of outputs receives damage. -- You are receiving this mail because: You are watching all bug changes.
