Files
x11-session-research/worklist.md
T
marfrit 9a023e9264 Phase 0: A1 Wayland baseline + state snapshot — major reframing
3 in-session reps of chromium-fourier 149 / brave_drops_test.html /
Plasma Wayland 6.6.4 (kwin-fourier 6.6.4-3 + qt6-base-fourier
6.11.0-3 carry-overs intact). Tight cluster IQR=0:
drops_total=0, drops_post_warmup=0, frames_total=1685, kwin %CPU
median=0.00, mean=0.04. Perf samples on kwin (~30 over 70s) show
zero composite/dmabuf/GL symbols — only event-loop bookkeeping.

Most likely mechanism: KWin direct-scanout fast-path engaged for
the single-visible-client video case. The campaign's load-bearing
hypothesis ("X11 + non-compositing WM avoids per-frame GL composite
of NV12") is structurally weakened — KWin already avoids that work
under Wayland for this workload. Phase 1 needs to add a
multi-window A1' variant and drm_info-during-playback to confirm
direct-scanout, then revisit matrix cell design.

revert.log entry 6: SDDM autologin + state.conf swap that landed
the Plasma Wayland session for the A1 reps. Backup of original
state.conf preserved at /var/lib/sddm/state.conf.x11-research-bak;
single-command revert documented.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 13:11:15 +00:00

8.1 KiB
Raw Blame History

Work items — x11-session-research

Governing rule (every phase)

Campaign-contained data acquisition. Every measurement this campaign relies on is acquired in this campaign's session. Predecessor numbers are reference history, never imported as binding cells, comparison targets, or success thresholds. The A1 baseline below is not optional — it is the in-session Wayland anchor against which X11 cells are compared. See phase0_findings.md § "Campaign-contained data discipline" and README.md § "Campaign-contained data discipline" for the full rule and the predecessor lesson that motivated it.

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.

  • 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).
  • 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?"
  • 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.
  • 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. Captured 2026-05-03 in phase0_evidence/wayland_baseline_2026-05-03/01_live_session.txt
    • 02_predecessor_assets.txt. Confirmed kwin_wayland 6.6.4 + qt6-base-fourier 6.11.0-3 + kwin-fourier 6.6.4-3 carry-overs intact, governor=performance, all three browsers + mpv installed, predecessor's run_browser_nodebug.sh + parsers + brave_drops_test.html test page reusable.
  • Inventory of available X11 paths on ohm. Captured 2026-05-03 in phase0_evidence/x11_inventory_2026-05-03/ (raw 02_x11_paths.txt + summary inventory.md § "Deliverable 2"). Verdict: xorg-server 21.1.22 + Mesa 26.0.5 / Panfrost healthy, modesetting (in-server) is sole DDX, only kwin_x11 WM installed today, six WM candidates available in extra, Plasma X11 + Plasma Wayland + Weston are the SDDM-advertised sessions. Operator action: pacman -S a non-compositing WM (recommend openbox) and create/switch to its SDDM session before without-KWin cells can run.
  • Browser X11-overlay-path inventory. Captured 2026-05-03 in phase0_evidence/browser_overlay_inventory_2026-05-03.md
    • acquired-source subtree phase0_evidence/chromium_ozone_x11_2026-05-03/ (Chromium 147 from chromium-builder LXD CT on boltzmann via the his subagent). Decisive verdict at the source level: Chromium ozone-x11 instantiates StubOverlayManager (ozone_platform_x11.cc:262) — no overlay candidates ever promoted; Brave 147 + chromium-fourier 149 inherit this unchanged (their patches don't touch Ozone). Firefox 150 WindowSurfaceX11{,Image,SHM} are RGB-only (zero NV12 / dmabuf / DRI3 / XPresent references in any X11-surface file). No browser in the matrix has a code path to hand NV12 to the X server for plane scanout. Only mpv --vo=xv does; mpv --vo=gpu --gpu-context=x11 is the same GL-composite shape as the browsers. Implication: campaign's load-bearing hypothesis is structurally weakened — the X11-vs-Wayland delta the matrix will measure for browsers is "browser-side GL composite + X-scanout-of-RGB" vs "browser-side GL composite + KWin-RGB-recomposite + scanout". mpv-xv becomes the matrix's only direct test of the original mechanism. Runtime-engagement probe deferred to Phase 1 first rep (design sketched in the inventory doc).
  • mpv added as 4th matrix client 2026-05-03. Two cells (full SW, libva/v4l2request) × 2 sessions × 2 VOs (--vo=xv and --vo=gpu --gpu-context=x11) = 8 reference data points. README + phase0_findings.md § "Experimental matrix" updated; matrix grew from 12 → 16 cells (+8 mpv VO sub-points). mpv 0.41.0 already installed via predecessor (see phase0_evidence/x11_inventory_2026-05-03/02_x11_paths.txt).
  • Inventory of X11-side measurement instruments. Captured 2026-05-03 in phase0_evidence/x11_inventory_2026-05-03/ (raw 04_measurement_instruments.txt + summary inventory.md § "Deliverable 4"). Live X server supports all 7 needed extensions (Composite, DAMAGE, DRI3, Present, RANDR, SYNC, XVideo). Tools installed: xprop, xdpyinfo, xset, glxinfo, drm_info, perf, mpv, libxcb-present. Tools missing-but-in-extra: xrandr CLI, xev, xinput, xwininfo, xkill, sysprof — one pacman -S away. AUR-only: X-protocol xtrace (the /usr/bin/xtrace from glibc is a syscall tracer, unrelated); optional, matrix doesn't strictly need protocol traces. perf_event_paranoid=2 — set to 1 once for unattended runs.
  • A1 baseline: in-session Wayland-with-KWin anchor. Captured 2026-05-03 14:2314:31 CEST in phase0_evidence/wayland_baseline_2026-05-03/a1_rep[1-3]/
    • verdict in a1_summary.md. 3 reps, chromium-fourier-kwin workload via run_browser_nodebug.sh. Tight cluster (IQR 0): drops_total=0, drops_post_warmup=0, frames_total=1685 (median), kwin %CPU median=0.00, mean=0.04. Major reframing finding: kwin_wayland is doing essentially zero per-frame work — perf reports show no GL / dmabuf / composite symbols at all, only event-loop bookkeeping. Most likely mechanism: KWin direct-scanout (single-visible-client bypass). The campaign's load-bearing hypothesis ("X11 will be measurably faster because no KWin GL composite") is structurally weakened — there's no per-frame KWin overhead for the X11 cells to be faster than. Phase 1 needs to add a multi-window A1' variant + drm_info-during-playback to confirm direct-scanout, plus revisit cell-design per a1_summary.md § "Phase 1 implications".

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. Thresholds are drawn from the A1 Wayland baseline acquired in this campaign — not from predecessor numbers. Provisional shape (numbers TBD from A1): a matrix cell counts as "X11 faster" if its effective fps exceeds the campaign's same-cell Wayland median by a margin larger than the campaign's same-cell Wayland IQR, and its drops_post_warmup is materially below the same cell's Wayland median.
  • 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

  • Campaign-contained data acquisition — see governing rule at the top of this file. The strongest version of the predecessor's "replicate the baseline first" lesson: don't import predecessor data at all, acquire it fresh.
  • 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.