Phase 0: browser X11-overlay inventory + mpv reference cell + tooling installs

Source-level verdict: no browser in the matrix has a code path
to hand NV12 to the X server for plane scanout. Chromium ozone-x11
wires StubOverlayManager (ozone_platform_x11.cc:262); Brave 147 +
chromium-fourier 149 inherit unchanged. Firefox WindowSurfaceX11
is RGB-only. The campaign's load-bearing hypothesis is structurally
weakened — what the X11 cells will measure for browsers is
KWin's per-frame RGB-recomposite cost, not the original
"force-GL-composite of NV12" framing. mpv --vo=xv becomes the
matrix's only direct test of the operator-supplied mechanism.

Matrix updated: 12 cells -> 16 cells (+8 mpv VO sub-points).
revert.log entries 1-5 capture all package + per-user state
mutations from this turn (measurement tools, openbox, XFCE +
xfwm4-no-comp pre-seed, firefox + AUR xtrace, XFCE rotation
+ touchscreen mapping); single SSH-driveable revert chain
returns ohm to its pre-campaign 1169-package state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

phase0_findings.md

@@ -279,17 +279,48 @@ dominates per browser × decode path.
 
 ### Experimental matrix
 
-Six 2-axis cells (3 browsers × 2 decode paths) × 2
-session conditions (with-KWin / without-KWin):
+Eight 2-axis cells (3 browsers + 1 reference client × 2 decode
+paths) × 2 session conditions (with-KWin / without-KWin):
 
-| Browser | Decode | with-KWin (Plasma Wayland) | without-KWin (X11 session, no compositor) |
+| Client | Decode | with-KWin (Plasma Wayland) | without-KWin (X11 session, no compositor) |
 |---|---|---|---|
 | Brave 147 | full SW | C-W-brave-sw | C-X-brave-sw |
 | Brave 147 | libva (if it works) | C-W-brave-libva | C-X-brave-libva |
 | chromium-fourier 149 (Step 1 + Step 2) | full SW | C-W-chrf-sw | C-X-chrf-sw |
 | chromium-fourier 149 | libva (Step 1 enables it) | C-W-chrf-libva | C-X-chrf-libva |
-| Firefox | full SW | C-W-ff-sw | C-X-ff-sw |
-| Firefox | libva | C-W-ff-libva | C-X-ff-libva |
+| Firefox 150 | full SW | C-W-ff-sw | C-X-ff-sw |
+| Firefox 150 | libva | C-W-ff-libva | C-X-ff-libva |
+| **mpv 0.41 (reference)** | **full SW** | **C-W-mpv-sw** | **C-X-mpv-sw** |
+| **mpv 0.41 (reference)** | **libva / v4l2request** | **C-W-mpv-hw** | **C-X-mpv-hw** |
+
+Each mpv cell is run twice — once with `--vo=xv` (XVideo
+extension, the legacy X11-hardware-overlay path mpv has used
+since the late 1990s) and once with `--vo=gpu --gpu-context=x11`
+(modern Mesa GL + DRI3 + XPresent path). Two VOs × 8 mpv cells
+= 16 mpv data points. The two mpv VOs probe orthogonal
+questions:
+
+- `--vo=xv`: does the X server's XVideo adapter route NV12 to
+  a hardware plane on rockchip-drm RK3568 at all? If yes,
+  XVideo is a known-good baseline that the browsers' more
+  modern overlay paths *should* match or beat.
+- `--vo=gpu --gpu-context=x11`: does the Mesa Panfrost
+  GL+DRI3+XPresent path on rockchip allow the X server to
+  route an NV12 dmabuf to Plane 39 (the Primary plane, the
+  only NV12-LINEAR-capable plane on this hardware)? This is
+  the same plumbing the browsers use, so a positive result
+  here means the browsers *could* but might not. A negative
+  result means even mpv can't, in which case the browsers
+  cannot either.
+
+mpv's role is **reference baseline**, not target. If both mpv
+VOs show clean hardware-overlay scanout but the browsers don't,
+the campaign verdict is "the X11 path is fast on this hardware,
+but the browsers leave the speedup on the table." If even mpv's
+two VOs can't engage Plane 39 NV12, the "X11 hardware-overlay
+mechanism is structurally avoidable" claim is challenged on
+this specific kernel/Mesa stack and the campaign needs to
+re-frame.
 
 The "(if it works)" / "where possible" qualifier per the
 operator's directive: libva on rockchip-drm RK3568 only works
@@ -298,7 +329,9 @@ stock Brave 147 and stock Firefox, libva probably doesn't
 engage and those cells are documented N/A. For Firefox, the
 Mesa-side `libva-v4l2-request` may make libva work via Mozilla's
 VAAPI backend even on stock Firefox — to be verified in
-Phase 0 inventory.
+Phase 0 inventory. mpv on this hardware should be able to
+engage `--hwdec=v4l2request-copy` (the Mesa libva-v4l2-request
+backend) for the libva mpv cells.
 
 ### What "cutting out the KWin compositor" means
 
@@ -357,15 +390,15 @@ unknown:
   presentation (rather than internally composing to RGB) is
   open. Mozilla has a `MOZ_X11_EGL` hint and a "hardware video
   overlay" pref but these are not universally engaged.
-- **Reference clients**: mpv with `--vo=xv` or
-  `--vo=gpu --hwdec=auto-copy --gpu-context=x11`, or `gst-play-1.0`
-  with `xvimagesink` or `glimagesink`, are known-good X11
-  hardware-overlay paths. **Adding mpv to the matrix as a
-  reference client** would isolate "does the X11 hardware-
-  overlay path work AT ALL on this hardware" from "do
-  browsers actually use it." If mpv hardware-overlays cleanly
-  but browsers don't, the conclusion is "the X11 path is fast,
-  but browsers leave the speedup on the table."
+- **Reference clients**: mpv was added to the matrix as a 4th
+  client (see § "Experimental matrix" above) — two cells, each
+  run with both `--vo=xv` and `--vo=gpu --gpu-context=x11` to
+  cover both the legacy XVideo overlay path and the modern
+  DRI3+XPresent+Mesa-GL path. `gst-play-1.0` with `xvimagesink`
+  or `glimagesink` would be a possible extension if the mpv
+  cells produce ambiguous results, but mpv alone covers the
+  "is the X11 hardware-overlay path even reachable on this
+  hardware" question.
 
 If the operator agrees, Phase 0 inventory should:
 
@@ -378,8 +411,8 @@ If the operator agrees, Phase 0 inventory should:
 2. Inventory Brave's, chromium-fourier's, and Firefox's X11
    overlay-presentation paths to see which (if any) request
    hardware-overlay presentation.
-3. Add mpv as a reference X11-overlay client to the matrix,
-   so the campaign has a known-good comparison point.
+3. ~~Add mpv as a reference X11-overlay client to the matrix~~
+   Done — mpv 0.41 added as a 4th client row 2026-05-03.
 
 ### What this question does NOT cover