Phase 0: motivation locked + mechanism captured

Operator-supplied research question 2026-05-03: "Does cutting
out the KWin compositor enable faster video display of Brave,
chromium-fourier, and Firefox — for full SW decoding, and for
libva decoding (where possible) — on PineTab2 RK3568?"

Operator-supplied mechanism 2026-05-03 (two messages):

1. "hantro emits NV12 which the GPU can't put on a
   compositeable plane. So that is the real bottleneck of
   Wayland."

   Connects directly to predecessor's Phase 1 finding
   (kwin_overlay_subsurface/phase2_source_findings.md:170-229):
   rockchip-drm overlay Plane 45 advertises no NV12 modifier;
   Primary Plane 39 supports NV12 LINEAR but is owned by KWin
   for its compositor framebuffer. Predecessor named the
   constraint but not the consequence — the consequence is
   that NV12 → RGB GL-composite is forced on Wayland-with-KWin
   regardless of which protocol path the browser uses.

2. "A X11 pipeline would route around that by giving a portion
   of screen real estate directly to the video pipeline."

   The X11 hardware-overlay path: with X11 + non-compositing
   WM, the X server can allocate Plane 39 (NV12 LINEAR) to
   the video region and Plane 45 (RGB AFBC) to the rest of
   the desktop. Hardware-blended at scanout. NO GL-composite
   anywhere — the cost the operator named as "the real
   bottleneck" is structurally avoided.

   This is the X11 hardware-overlay mechanism that historically
   made X11 desktops good at video playback (Xv → modern
   DRI3 + XPresent + Composite-redirection-disabled).
   Wayland-with-monolithic-compositor designs cannot use this
   freedom: the compositor must own the Primary plane, so the
   plane-allocation freedom required to put NV12 video on
   Plane 39 alongside RGB chrome on Plane 45 isn't available.

phase0_findings.md updated with:
- Locked research question + 12-cell experimental matrix
  (3 browsers × 2 decode paths × 2 sessions; some N/A).
- Three separable cost components the matrix tests for
  (mandatory NV12→RGB GL conversion if hardware-overlay
  doesn't engage, fallback GL-composite, per-frame compositor
  overhead independent of NV12).
- Open questions about whether browsers actually request
  hardware-overlay presentation under X11, or whether they
  always internally composite to RGB.
- Recommendation to add mpv as a reference X11-overlay
  client: distinguishes "X11 path works on this hardware"
  from "browsers actually use the X11 path."

worklist.md updated:
- Phase 0 motivation + matrix items ticked.
- Pre-Phase-1 inventory broken out: state snapshot, X11
  path inventory, browser-overlay-path inventory, mpv
  reference, X11 measurement-tool inventory, A1 Wayland
  baseline anchor.
- Phase 1 sketch: binding cells per matrix cell, clear-pass /
  clear-fail thresholds, measurement protocol mirroring the
  predecessor's phase3_protocol.md structure.

README banner updated to reflect locked motivation +
mechanism summary + matrix shape.

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

worklist.md

@@ -1,39 +1,94 @@
 # Work items — x11-session-research
 
-## Phase 0 — substrate + research question framing
+## Phase 0 — substrate + research question + inventory
 
-**Status: IN PROGRESS.** Substrate doc landed
-(`phase0_findings.md`). Research question is provisional,
-awaits operator confirmation. Pre-question Phase 0 deliverables
-listed below are unblocked.
+**Status: IN PROGRESS.** Motivation LOCKED 2026-05-03 in
+`phase0_findings.md` § "Research question". Pre-Phase-1
+inventory and baseline-anchor work below.
 
-- [x] Predecessor close-out summarised. Substrate doc
-  (`phase0_findings.md`) lists what stays valid from
-  `kwin_overlay_subsurface`, what's specific to Wayland and
-  doesn't transfer, and three plausible outcome shapes (α/β/γ)
-  for the candidate research question.
-- [ ] **Operator confirms the research question.** Three
-  candidate framings + four alternates are listed in
-  `phase0_findings.md` § "Research question (provisional)".
-  Pick one (or correct the framing) before Phase 1.
+- [x] Predecessor close-out summarised. Substrate doc lists
+  what transfers from `kwin_overlay_subsurface` and what's
+  Wayland-specific (KWin source-reads don't transfer to X11
+  path).
+- [x] **Research question locked.** "Does cutting out the
+  KWin compositor enable faster video display of Brave,
+  chromium-fourier, and Firefox — for full SW decoding, and
+  for libva decoding (where possible) — on PineTab2 RK3568?"
+- [x] **Mechanism captured.** Operator-supplied insight
+  2026-05-03: hantro emits NV12, rockchip-drm overlay plane
+  doesn't accept NV12, so KWin must own the only NV12-capable
+  plane (Primary, Plane 39) and forces GL-composite of every
+  NV12 buffer. X11 + non-compositing WM can give the video
+  region directly to Plane 39 and put rest of desktop on
+  Plane 45 (RGB AFBC) — hardware-blended, no GL-composite.
+- [x] **Experimental matrix drafted.** 3 browsers × 2 decode
+  paths × 2 sessions = 12 cells (some N/A where libva isn't
+  supported). See `phase0_findings.md` § "Experimental matrix".
 - [ ] State snapshot of ohm under current Plasma Wayland —
-  the campaign-start *before* photo. Unattended-tractable.
-- [ ] Inventory of available X11 paths on ohm: installed
-  packages, SDDM-advertised sessions, alternate WMs,
-  XWayland availability. Read-only.
-- [ ] Inventory of measurement instruments that work under
-  X11. `xtrace`, frame-timing tooling, perf on Xorg PID, etc.
-  Read-only.
-- [ ] A1 baseline: 1× `kwin_timing_nodebug`-equivalent run
-  on current Plasma Wayland session, captured into
-  `phase0_evidence/wayland_baseline_rep1/`. Same-session
-  anchor for any future X11 comparison.
+  the campaign-start *before* photo. Unattended-tractable
+  via SSH. Captures package versions, kernel, kwin_wayland
+  PID + cmdline, governor, services, browser binary versions,
+  test asset paths, thermal_zone temps.
+- [ ] Inventory of available X11 paths on ohm:
+  - Installed packages: `xorg-server`, `xorg-xinit`,
+    `xorg-xrandr`, drm/dri stack, `mesa-x11` if separated.
+  - SDDM-advertised sessions: list `/usr/share/xsessions/*`.
+  - Alternate WMs available (openbox, fluxbox, xfwm4, i3,
+    etc.) — what's installed, what'd need installing.
+  - Whether modesetting Xorg driver (`xf86-video-modesetting`)
+    is the active driver path on rockchip-drm, vs an older
+    armsoc/fbdev driver.
+  - XWayland availability and version (relevant only as a
+    third comparison axis — primary X11 cells are NATIVE
+    Xorg, not XWayland).
+- [ ] **NEW: Browser X11-overlay-path inventory.** Per
+  `phase0_findings.md` § "Open questions": determine whether
+  Brave 147 ozone-x11, chromium-fourier 149 ozone-x11, and
+  Firefox X11 backends actually request hardware-overlay
+  presentation for windowed video, or whether they always
+  internally composite to RGB. Browser-specific source-grep
+  + chrome trace inspection.
+- [ ] **NEW: Add mpv as a reference X11-overlay client.**
+  mpv with `--vo=xv` or `--vo=gpu --gpu-context=x11` is a
+  known-good X11 hardware-overlay path. Adding mpv to the
+  matrix as a 4th client provides "is the X11 hardware-overlay
+  path even reachable on this hardware" baseline, separate
+  from "do browsers use it." If mpv hits Plane 39 NV12 cleanly
+  but browsers don't, the answer is "X11 path is fast, but
+  the browsers don't take advantage of it."
+- [ ] Inventory of X11-side measurement instruments. Available
+  options: `xtrace` (X protocol tracer), `xev` (event viewer),
+  `xprop` (window properties), `xrandr --verbose` (output
+  state), `glxinfo`, `compton-trans` for compositor detection,
+  perf on Xorg PID. Frame-timing under X11 typically uses
+  `XPresent` notify events or `INTEL_swap_event` GLX
+  extension equivalents — what's available on rockchip is
+  open.
+- [ ] **A1 baseline: Wayland-with-KWin reference rep.**
+  1× `kwin_timing_nodebug`-equivalent run on current Plasma
+  Wayland session captured into
+  `phase0_evidence/wayland_baseline_rep1/` as the
+  same-session anchor for the cross-session
+  Wayland-vs-X11 comparison. Per
+  `feedback_replicate_baseline_first.md`.
 
-## Phase 1 — locked research question + binding cells
+## Phase 1 — binding cells + measurement protocol
 
-**Pending operator confirmation of the Phase 0 question.**
-Phase 1 lock will produce `phase1_lock.md` with binding cells
-specific to whichever framing is locked.
+**Pending Phase 0 inventory + A1 baseline anchor.** Phase 1
+lock will produce `phase1_lock.md` with:
+
+- Binding cells per matrix cell (effective_fps, drops_total,
+  drops_post_warmup, end-to-end-latency-if-testable,
+  compositor+browser CPU at steady state).
+- The clear-pass / clear-fail thresholds: what "X11 is faster"
+  means quantitatively. Provisional: a matrix cell counts as
+  "X11 faster" if effective_fps under X11 is ≥ 28 (out of 30
+  source) AND drops_post_warmup is ≤ 5, on a same-session
+  cross-paired comparison with the corresponding Wayland cell.
+- The measurement protocol per matrix cell, including how the
+  X11 sessions are entered and how the browser is launched
+  with libva forced on/off. Mirrors the structure of
+  `kwin_overlay_subsurface/phase3_protocol.md`.
 
 ## Phase 2-onwards