# Work items — x11-session-research

## Phase 0 — substrate + research question + inventory

**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 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
  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 — binding cells + measurement protocol

**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

Pending.

## Discipline carry-overs from `kwin_overlay_subsurface`

- *Replicate the baseline first* — per
  `feedback_replicate_baseline_first.md`. Phase 0 task "A1
  baseline" exists specifically because of this lesson; do not
  skip it.
- *Phase discipline* — no patches before source-read is
  documented. Re-scoping must be honest about deferral target.
- *Non-upstreaming default* — bug reports + MRs are explicit
  operator-tasked decisions.
- *Memory persistence rule* — when this campaign reaches its
  diagnostic terminal state (success or honest closure), update
  `project_campaign_overview.md` and add any new feedback
  memory worth carrying forward to the next campaign.