Panther Lake (b082) eDP tearing tied to Panel Replay/selective-fetch, Anapass T-Con (OUI ba:41:59)

Panther Lake (b082) eDP tearing tied to Panel Replay/selective-fetch, Anapass T-Con (OUI ba:41:59)

[Fredrik Nicol]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4515 bytes --]

Re: Panther Lake (b082) eDP tearing tied to Panel Replay/selective-fetch, Anapass T-Con (OUI ba:41:59)

[Jani Nikula]

On Wed, 26 Aug 2026, Fredrik Nicol <fredrik.nicol@strategic9.se> wrote:
> 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.

Sorry for the delayed response. Please file a bug as described at [1].

Thanks,
Jani.

[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html


-- 
Jani Nikula, Intel