Native X11 in XFCE / xfwm4-no-comp on tty7 / session 510.
Q1 (mechanism: does X server route NV12 to a hardware plane?):
NEGATIVE. Across 4 mpv VO × decode combinations
(--vo=xv ± hwdec, --vo=gpu ± hwdec), Plane 39 stayed XRGB8888
with FB ID 62 throughout. mpv-xv falls back to XShm software
put-image; mpv-gpu does GL composite via DRI3 + XPresent of an
RGB framebuffer; chromium-fourier-x11 same shape. No path on
this rockchip-drm + Mesa Panfrost + modesetting Xorg stack
engages hardware-overlay scanout for an NV12 client.
Q4 (browser X11 vs Wayland on same workload): the campaign
hypothesis is OPPOSITE to the data. chromium-fourier-x11 ×3
median: drops_post_warmup=9, frames_total=1532, fps=21.8.
Compare to A1 Wayland ×3 median: drops_post_warmup=0,
frames_total=1685, fps=24.04. X11 + xfwm4-no-comp is worse
than Plasma Wayland-with-KWin on every metric.
Likely cause: KWin's vblank-aligned wp_presentation_feedback
buffer scheduling absorbs client timing jitter; X11 + no
compositor exposes that jitter directly to the page's
getVideoPlaybackQuality() drop counter.
Operator subjective note: "first mpv was perfect" for
mpv-xv-sw despite mpv stderr "X11 can't keep up". 1080p24 SW
Xv is perceptually smooth on this hardware even though
instrumentation flagged it as struggling.
x1_summary.md surfaces three legitimate next moves: honest
closure, reframe to operator-experience-driven Wayland-stutter
scenarios, or pivot to client/driver-layer mechanism work
(modesetting NV12 Xv adapter, chromium hw-overlay flags).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit
3d49582ed0