# Update — workaround developed, root cause partially identified
After several hours of investigation I've identified the root cause and built
a
working in-kernel mitigation. Sharing in case it's useful for the maintainers
or other affected users.
## Hardware / software
- Dell XPS 15 9530 (Raptor Lake-P / Alder Lake-P)
- eDP-1: panel marker "4DWVJ" (IGZO IPS 1920x1200, Dell KB 000218908 lists
this panel as known-flicker)
- Ubuntu 26.04 Desktop classic (model `ubuntu-classic-2604-amd64`),
snap-managed pc-kernel, grade `signed`, Enhanced Secure Boot FDE
- Kernel: 7.0.0-15-generic (current pc-kernel snap)
- i915 driver active (xe also loaded but inactive on this iGPU)
## Root cause
Two compounding issues:
1. **VBT is generic / not customised for the actual panel**:
- Panel name field is the placeholder string "LFP_PanelName"
- Reported resolution is 1024x768 (the panel is 1920x1200)
- PSR `Idle frames before enable` = 3 (very aggressive; conservative
defaults are 16+)
- PSR + DRRS combination known to misbehave on this panel
2. **The 4DWVJ panel firmware itself oscillates** between PSR states
autonomously (sink status alternates 0x2 / 0x4 / 0x0 in a tight loop
visible at /sys/kernel/debug/dri/*/eDP-1/i915_psr_sink_status).
Each timing re-sync triggers a cascade in the source side: link retrain
→ PCIe re-enumeration on the Thunderbolt bus → the famous USB
"clink-clong" of the Dell TB15/TB16 dock + brief Bluetooth disconnect
on hci0. This last part is what makes the bug user-visible.
## Why the standard workarounds don't apply on Ubuntu 26.04
grade=signed
| Standard mitigation | Why it fails here |
|---------------------|-------------------|
| `i915.enable_psr=0` via GRUB | No GRUB; snap-bootstrap + systemd-boot |
| `snap set system system.kernel.cmdline-append=...` | Gadget snap (pc/220)
whitelist allows only `quiet` and `splash` |
| `system.kernel.dangerous-cmdline-append=...` | Requires model grade
`dangerous`; this image is grade `signed` |
| `/etc/modprobe.d/i915.conf options i915 enable_psr=0` | Ignored: i915 loads
from the initrd embedded in `kernel.efi` before the rootfs is mounted |
| Write `/sys/module/i915/parameters/enable_psr` | Mode 0400 (read-only) |
| Write `/sys/kernel/debug/dri/.../i915_edp_psr_debug` | Blocked by kernel
lockdown=integrity (Secure Boot) |
| Recompile i915 with a quirk | Cannot be unloaded online (active clients);
the initrd-embedded i915 always wins |
This is, in practice, a class of regression for any system that:
- Uses snap-based pc-kernel
- Has FDE Enhanced + Secure Boot
- Has a panel that requires `i915.enable_psr=0`
## Workaround I'm running now
Signed out-of-tree kernel module that combines two layers:
1. **klp_func livepatch** replacing `intel_psr_compute_config` and
`intel_psr_enable_locked` of the i915 module with no-ops.
2. **kprobe** on `intel_psr_init_dpcd@i915` that, on each connector
re-detect, calls `intel_psr_debug_set(intel_dp, I915_PSR_DEBUG_DISABLE)`
via a workqueue.
The module is signed with the NVIDIA Driver Signing MOK (already enrolled in
this system), so Secure Boot stays enabled and TPM PCR sealing for FDE is
not perturbed. DKMS handles automatic recompilation across kernel updates.
This eliminates the flicker, the dock USB cascade and the Bluetooth drops
in real-world use.
## What would actually help from Canonical / upstream
Either of these would solve it cleanly without per-user workarounds:
1. **Add `i915.enable_psr` to the gadget pc snap kernel cmdline whitelist**
(alongside `quiet` and `splash`). It's a well-known stable parameter and
would unblock everyone on grade=signed images with PSR-affected panels.
2. **Add a quirk in `intel_psr_init` for panels with placeholder VBT
("LFP_PanelName" + 1024x768 resolution + PSR enabled)** — that combination
is a strong indicator of an OEM-shipped VBT that wasn't customised for
the actual installed panel, and PSR should be defaulted to off in that
case.
3. Alternatively, **a quirk specifically matching the Dell 4DWVJ panel
manufacturer/model identifier** (Dell KB 000218908 already documents the
issue and Dell's recommendation is "disable PSR" — a kernel-side quirk
would mirror that).
The Latitude 7430/9430 case in LP #2065096 is the same underlying issue
manifested differently because those models are not on grade=signed.
Happy to provide more diagnostic data, kernel logs, ftrace captures or test
patches against current trunk.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2152105
Title:
i915 PSR causes display+USB+BT glitches on XPS 15 9530; kernel cmdline
whitelist on 26.04 blocks i915.enable_psr=0 workaround
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2152105/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
