marfrit/x11-session-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e8bae670d366f43bae6c8201ab5fcedfe37cf33f
x11-session-research/worklist.md
T
marfrit e8bae670d3 Campaign-contained data discipline + repo notice 
Operator directive 2026-05-03: this campaign acquires all its
own measurement data from scratch. Predecessor numbers are
documented for context but never imported as binding cells,
comparison targets, or success thresholds. The lesson the
predecessor (kwin_overlay_subsurface) closed-without-patch on
is exactly that: phase 1 cells anchored to a single historical
ohm_gl_fix Phase 0 measurement, three weeks of phase planning
on a baseline that didn't reproduce in-session.

The strongest version of feedback_replicate_baseline_first.md:
"don't import predecessor data, acquire it fresh." The discipline
is now documented as a governing rule in three places:

- README.md § "Campaign-contained data discipline"
- phase0_findings.md § "Campaign-contained data discipline
  (governing rule)"
- worklist.md § "Governing rule (every phase)"

Concrete consequences:
- A1 baseline (Phase 0 task) is now mandatory at N=3 reps.
  Single-rep wasn't enough to surface session variance in the
  predecessor; doing 3 up front makes the baseline robust to
  the same kind of session-state drift that ate the
  predecessor's premise.
- Phase 1 thresholds are drawn against the A1 baseline measured
  in this campaign, not against any predecessor number.
- metrics.csv (when it lands) only carries data from this
  campaign's reps. No predecessor rows imported.

README.md additionally:
- Adds the predecessor chain (ohm_gl_fix -> kwin_overlay_subsurface
  -> this campaign) with explicit "what stays valid for source-
  reading" vs "numbers that don't" separation.
- Calls out durable substrate available from predecessors:
  KWin scanout-promotion archaeology, measurement-protocol
  template, WAYLAND_DEBUG parser. All structural; none
  measurement-numerical.
- Carry-over predecessor system state on ohm (governor pin,
  baloo disabled, fourier packages) is explicitly distinguished
  from measurement data. System state inherits; data does not.
- Repository line points to the gitea remote
  ssh://gitea@git.reauktion.de:2222/marfrit/x11-session-research.git

phase0_findings.md additionally:
- Reframes the predecessor-close-out summary section header to
  "(context, not data)" and rephrases past-tense numbers so
  none are stated as "the baseline."
- Adds the discipline lesson narrative in-line before the
  predecessor close-out: a 30-minute N=3 same-session baseline
  on day 1 of the predecessor would have made the campaign
  different — and that's the move this campaign starts with.

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

132 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.
- [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: in-session Wayland-with-KWin anchor.**
Mandatory per the governing rule. 3 reps minimum (variance
is a real concern on this hardware per the predecessor
data) of a `kwin_timing_nodebug`-equivalent run on the
current Plasma Wayland session, captured into
`phase0_evidence/wayland_baseline_repN/`. **This is the
only Wayland baseline this campaign uses.** No
predecessor number substitutes for these reps even if the
predecessor measured an "identical" condition. The 3 reps
also surface the session-internal variance up front, so
Phase 1 thresholds aren't drawn against a single sample.
## 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.
Reference in New Issue View Git Blame Copy Permalink