Hi, I'm running into a persistent display bug on a Panther Lake handheld (OneXPlayer 3, GPU device ID 8086:b082) that I've traced fairly deep into the xe driver's Panel Replay/selective-fetch path, and I wanted to get this in front of someone who can actually act on it rather than let it sit undocumented. I'm a developer, not a kernel contributor, so apologies if some of this is presented a bit sideways from how you'd normally see a bug report, but I've tried to keep everything here verifiable.
Hardware: internal panel is Samsung Display AMS881KB01-0, 8.8" AMOLED, 1920x1200 up to 144Hz. The panel controller (confirmed by reading the sink IEEE OUI directly off the eDP AUX channel at DPCD 0x400) is Anapass Inc., OUI ba:41:59. EDID reports native 12bpc and BT2020/PQ HDR static metadata. Notably this is the exact same panel model used in the Lenovo Legion Go 2, which runs AMD hardware and doesn't appear to have this issue, so I don't think the panel itself is at fault. Symptom: visible tearing and garbled pixel regions on the internal display, worse during motion (scrolling, animation, gameplay), still present but less frequent when the screen is static. Confirmed independently on two separate distros (CachyOS and a stock Bazzite live session), so it isn't something specific to my install. The dmesg signature, first appearing during early boot and recurring on subsequent modesets: xe 0000:00:02.0: [drm] Port A asks to use VBT vswing/preemph tables WARNING: drivers/gpu/drm/i915/display/intel_bios.c:2788 at intel_bios_init xe 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A xe 0000:00:02.0: [drm] *ERROR* [CRTC:151:pipe A] mismatch in vsc dp vsc sdp expected: BT.2020 RGB, bpc: 10 found: sRGB, bpc: 0 pipe state doesn't match! (stack through intel_modeset_verify_crtc / intel_atomic_commit_tail, Workqueue: i915_modeset intel_atomic_commit_work) I ran a full bisection across the relevant xe module parameters, each tested in isolation and in combination, confirmed via /sys/kernel/debug/dri/.../eDP-1/i915_psr_status after each boot rather than assumed from the parameter alone: xe.enable_psr=0 + xe.enable_psr2_sel_fetch=0 + xe.enable_panel_replay=0: black screen, no display xe.enable_psr2_sel_fetch=0 alone: black screen xe.enable_psr=0 + xe.enable_panel_replay=0 (sel_fetch left on): black screen xe.enable_panel_replay=0 alone: display works, tearing persists (confirmed fallback to PSR1 via psr_status) xe.enable_psr=0 alone: display works, tearing persists So there's no combination of these three flags that gives a working, tear-free display. Anything that disables selective-fetch takes the modeset down entirely, and anything that leaves it enabled still tears. That felt like the most useful concrete result to hand over, since it rules out a boot-parameter workaround existing at all on this hardware. One more thing worth flagging: this is intermittent, not deterministic. Identical kernel, identical boot parameters, identical hardware has produced different outcomes across separate boots, and switching between gamescope and a desktop compositor session reliably re-triggers a fresh roll of the dice. I also have one report from someone with a confirmed-identical OUI (ba:41:59, verified the same way) who says they don't see this at all on the same kernel version, so whatever margin this is riding on isn't purely software-version-gated. I'm aware there's already a precedent for handling this class of problem, the QUIRK_DISABLE_PANEL_REPLAY / intel_dpcd_quirks[] entry added for the Dell XPS 14's panel (OUI 00:22:b9). I haven't found anything in that table for ba:41:59, and given how closely this matches (down to the exact same "Selective fetch area calculation failed in pipe A" line) what's been separately reported on at least one other OEM's Panther Lake machine with a different panel entirely, I think this may be a broader selective-fetch issue rather than something isolated to my specific panel. Happy to pull more logs, test patches, or run anything else that would help narrow this down. I've got full dmesg captures from multiple boots, the raw EDID dump, and the psr_status output from each of the bisection runs above if useful. Thanks for reading this far. Fredrik
