Screen exhibits a periodic visual glitch that looks like "the top part of the screen being pulled down" / a brief tearing-like distortion at the bottom portion of the display. It is accompanied by an audible clicking sound similar to a cable/connection repeatedly making and breaking contact.
Occurs after the system has been running for a while (not immediately after boot)
Occurs regardless of workload (idle browsing, video playback, gaming via Steam/Proton)
Never occurs under Windows on the same physical device
Also occurs when booting from a fresh Ubuntu live USB stick (no custom configuration, no kernel parameters, no installed packages)
Does not occur in the GRUB boot menu (i.e. before any Linux graphics driver loads)
What has been ruled out
Tested extensively across two kernels (6.19.8-surface-3 and stock 7.0.0-27-generic) and multiple sessions:
PSR (Panel Self Refresh): disabled via i915.enable_psr=0, confirmed 0 in both /sys/module/i915/parameters/enable_psr and /proc/cmdline — no change
PSR2 selective fetch (enable_psr2_sel_fetch=Y) — present but disabling not yet root cause (see below)
Kernel version: identical behavior on linux-surface kernel and stock generic kernel
Display server: identical behavior on Wayland and Xorg (GNOME "Ubuntu" and "Ubuntu on Xorg")
KDE/Kubuntu-desktop coexistence: no kwin/plasmashell processes running alongside gnome-shell, ruled out
TearFree (modesetting driver, Option "TearFree" "true"): no effect
Temperature: consistently below 38°C during occurrences (via sensors), thermal throttling ruled out (CPU frequency stable)
Screen brightness: tested at 94%, no change (PWM backlight flicker theory ruled out)
i915.invert_brightness=1: no change
Power adapter connected vs. disconnected: no change
IPTS (touchscreen digitizer) restart events in dmesg: not correlated in time with the visual glitch (checked live via dmesg -w)
Steam client and all related processes fully killed (pkill -9 -f steam): no change
GNOME idle-dim / screensaver / animations disabled via gsettings: no change
Full unfiltered dmesg -w monitored live across >1 hour spanning multiple occurrences of the glitch: zero new kernel log lines appear at the time of the glitch — no i915/drm/USB/ACPI events logged
Key observation
Since the issue reproduces on a stock Ubuntu live USB session with zero configuration changes, and does not appear in GRUB, it appears to be triggered specifically by the Linux i915 graphics driver/stack interacting with this unit's (aging, ~10 year old) display panel — but leaves no trace in the kernel log, suggesting the fault may occur at a level i915 doesn't treat as an error (signal/timing related) or on the userspace/Mesa side.
Question
Has anyone else observed this specific pattern (audible click + bottom-of-screen tearing/pull-down effect, no kernel log correlation, absent under Windows, absent in GRUB, present on stock live USB) on Surface Pro 4 units? Any known workaround or additional diagnostic step (e.g. specific i915 debug flags, intel_reg dumps, or a way to capture pipe/CRC errors during the glitch) would be greatly appreciated.
Happy to provide intel_gpu_top, journalctl, or dmesg output around further occurrences if it would help — just let me know what to capture.
Screen exhibits a periodic visual glitch that looks like "the top part of the screen being pulled down" / a brief tearing-like distortion at the bottom portion of the display. It is accompanied by an audible clicking sound similar to a cable/connection repeatedly making and breaking contact.
Occurs after the system has been running for a while (not immediately after boot)
Occurs regardless of workload (idle browsing, video playback, gaming via Steam/Proton)
Never occurs under Windows on the same physical device
Also occurs when booting from a fresh Ubuntu live USB stick (no custom configuration, no kernel parameters, no installed packages)
Does not occur in the GRUB boot menu (i.e. before any Linux graphics driver loads)
What has been ruled out
Tested extensively across two kernels (6.19.8-surface-3 and stock 7.0.0-27-generic) and multiple sessions:
PSR (Panel Self Refresh): disabled via i915.enable_psr=0, confirmed 0 in both /sys/module/i915/parameters/enable_psr and /proc/cmdline — no change
PSR2 selective fetch (enable_psr2_sel_fetch=Y) — present but disabling not yet root cause (see below)
Kernel version: identical behavior on linux-surface kernel and stock generic kernel
Display server: identical behavior on Wayland and Xorg (GNOME "Ubuntu" and "Ubuntu on Xorg")
KDE/Kubuntu-desktop coexistence: no kwin/plasmashell processes running alongside gnome-shell, ruled out
TearFree (modesetting driver, Option "TearFree" "true"): no effect
Temperature: consistently below 38°C during occurrences (via sensors), thermal throttling ruled out (CPU frequency stable)
Screen brightness: tested at 94%, no change (PWM backlight flicker theory ruled out)
i915.invert_brightness=1: no change
Power adapter connected vs. disconnected: no change
IPTS (touchscreen digitizer) restart events in dmesg: not correlated in time with the visual glitch (checked live via dmesg -w)
Steam client and all related processes fully killed (pkill -9 -f steam): no change
GNOME idle-dim / screensaver / animations disabled via gsettings: no change
Full unfiltered dmesg -w monitored live across >1 hour spanning multiple occurrences of the glitch: zero new kernel log lines appear at the time of the glitch — no i915/drm/USB/ACPI events logged
Key observation
Since the issue reproduces on a stock Ubuntu live USB session with zero configuration changes, and does not appear in GRUB, it appears to be triggered specifically by the Linux i915 graphics driver/stack interacting with this unit's (aging, ~10 year old) display panel — but leaves no trace in the kernel log, suggesting the fault may occur at a level i915 doesn't treat as an error (signal/timing related) or on the userspace/Mesa side.
Question
Has anyone else observed this specific pattern (audible click + bottom-of-screen tearing/pull-down effect, no kernel log correlation, absent under Windows, absent in GRUB, present on stock live USB) on Surface Pro 4 units? Any known workaround or additional diagnostic step (e.g. specific i915 debug flags, intel_reg dumps, or a way to capture pipe/CRC errors during the glitch) would be greatly appreciated.
Happy to provide intel_gpu_top, journalctl, or dmesg output around further occurrences if it would help — just let me know what to capture.