From ac301b4e4827cf504baf9b4b0141bd66ecb6f7ff Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Sun, 3 May 2026 06:49:18 +0000 Subject: [PATCH] Phase 0: motivation locked + mechanism captured MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- README.md | 40 +++--- phase0_findings.md | 304 +++++++++++++++++++++++++++++++++++++-------- worklist.md | 113 ++++++++++++----- 3 files changed, 358 insertions(+), 99 deletions(-) diff --git a/README.md b/README.md index 0419da1..6cb961f 100644 --- a/README.md +++ b/README.md @@ -1,21 +1,31 @@ # x11-session-research -> **Status: PHASE 0 — research question pending operator -> confirmation.** See [`phase0_findings.md`](phase0_findings.md) -> § "Research question (provisional)" for the candidate framing -> drafted from the predecessor campaign's close-out. Phase 1 -> lock will not happen before the operator confirms or -> redirects. +> **Status: PHASE 0 — motivation locked 2026-05-03.** +> See [`phase0_findings.md`](phase0_findings.md) § +> "Research question (LOCKED 2026-05-03)". Phase 1 still +> requires the four pre-question Phase 0 deliverables +> (state snapshot, X11 path inventory, browser-overlay-path +> inventory, baseline anchor) before binding cells lock. -Campaign to investigate X11 session behaviour on PineTab2 -RK3568, in the context of the just-closed -[`kwin_overlay_subsurface`](../kwin_overlay_subsurface/) -campaign. Whether running an X11 (Xorg) session on the same -hardware would (a) reproduce the drop-inversion phenomenon -that motivated the predecessor, (b) bypass it entirely, or -(c) introduce a different set of constraints, is the most -likely campaign question — but this is a working assumption, -not a locked goal. See `phase0_findings.md`. +**Research question:** 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? + +The operator-supplied mechanism: hantro decodes to NV12; +rockchip-drm's overlay plane cannot accept NV12, so on Wayland +KWin must own the only NV12-capable plane (Primary, Plane 39) +for its compositor framebuffer, which forces a GL-composite +of every NV12 video buffer. X11 + non-compositing WM can give +the video region directly to Plane 39 (NV12 native) and put +the rest of the desktop on Plane 45 (RGB AFBC), avoiding the +forced GL-composite. **The campaign's load-bearing hypothesis +is that this plane-allocation freedom translates into +measurable browser-video speedup.** + +The matrix is 3 browsers × 2 decode paths × 2 sessions = 12 +cells (some N/A where libva isn't supported). See +`phase0_findings.md` for the full table. ## Predecessor diff --git a/phase0_findings.md b/phase0_findings.md index 8d2f35e..48e3dea 100644 --- a/phase0_findings.md +++ b/phase0_findings.md @@ -99,70 +99,264 @@ If this campaign needs to switch ohm to an X11 session, that is a session-level operator action (logout, switch via SDDM, log back in). It cannot be done unattended. -## Research question (provisional — awaits operator confirmation) +## Research question (LOCKED 2026-05-03) -**Candidate framing**, not 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?"* -> *"On PineTab2 RK3568 with the same chromium-fourier binary, -> the same `bbb_1080p30_h264.mp4` 30 fps source clip, and the -> same `brave_drops_test.html` instrumented page, does running -> an X11-session display server (Plasma X11, or an alternative -> X11 desktop) reproduce the drop-inversion phenomenon that -> motivated `kwin_overlay_subsurface`, eliminate it, or -> introduce a different drop characteristic?"* +### Mechanism the question targets -This is the most narrowly relevant question given the -predecessor's close-out. Three plausible outcomes: +Operator-supplied context 2026-05-03: -- **(α)** X11 reproduces low post-warmup drops (matches Phase 0 - cage = 0 floor): isolates the dropped-frames mechanism to - the Wayland compositor stack on this hardware. The original - campaign's framing was correct in spirit but the cage - comparison was confounded; X11 becomes the better - comparator. -- **(β)** X11 has comparable or higher post-warmup drops: the - drop phenomenon is hardware/kernel/Mesa-bound and does not - localise to the display-server stack at all. Predecessor's - Phase 8 closure stands; the X11 measurement is the - decisive cross-check. -- **(γ)** X11 has a different failure mode entirely (different - drop pattern, different perf hot symbols, different effective - fps): each finding is its own characterisation; the - campaign becomes "what does running X11 on this hardware - look like end-to-end." +> *"hantro emits NV12 which the GPU can't put on a +> compositeable plane. So that is the real bottleneck of +> Wayland."* -**Alternate framings** the operator may have in mind that -this provisional question doesn't cover: +This connects directly to the predecessor's Phase 1 finding +(`kwin_overlay_subsurface/phase2_source_findings.md`:170-229): -- *Daily-driver fitness*: "Can I use X11 instead of Wayland on - this device for everyday browser/video/desktop work, and - what works/breaks?" — different scope; less measurement-heavy, - more workflow-oriented. -- *Specific X11-only feature investigation*: composite - redirection, XRender, GLAMOR, Xinerama on a single-display - device, etc. -- *XWayland behaviour*: many Linux desktops run X11 clients - under Wayland via XWayland. If an "X11 session" really means - "test under XWayland to compare with native Wayland", the - measurement is fundamentally different. -- *Power consumption / thermal*: X11 vs Wayland on a passively - cooled tablet may differ in idle CPU and thermal envelope. - Different metric set. +- Hantro VPU decodes H.264 video into NV12 dmabufs (`DRM_FORMAT_NV12`, + `DRM_FORMAT_MOD_LINEAR`). +- rockchip-drm's only NV12-LINEAR-capable plane is the + Primary plane (Plane 39 on CRTC 52), which the running KWin + uses for its GL framebuffer. +- The overlay plane (Plane 45) advertises no NV12 in any + modifier in `IN_FORMATS`. +- Therefore **no rockchip-drm scanout plane can accept the + NV12 buffer hantro produces while KWin owns the primary + plane.** Some compositing step must convert NV12 → RGB + before display. -**Operator decision needed before Phase 1**: +The predecessor named the *constraint* (Path B rejected at +the format/modifier intersection) but the *consequence* — +"some component must GL-composite NV12 → RGB on the GPU +because nothing else on this hardware can put NV12 on a +scanout plane" — was not made explicit. That consequence is +this campaign's motivating insight: -1. Which question is in scope? (drop phenomenon, daily-driver, - feature-specific, XWayland-vs-native, power, or something - else). -2. What "X11 session" means specifically: native Xorg + Plasma - X11; native Xorg + lightweight WM (e.g. openbox / i3 / xfwm); - XWayland under the existing Plasma Wayland session; or - another configuration. -3. What the success/failure criteria look like (binding cells, - `metrics.csv` shape). +- **Under Plasma Wayland:** when the browser engages the + Wayland subsurface route (chromium's + `WaylandBufferManagerHost::CommitOverlays`), KWin receives + an NV12 dmabuf and must GL-composite it. **KWin's compositor + is the GL-composite step.** When the browser does NOT + engage the subsurface route (the predecessor's measured + case on `brave_drops_test.html` — zero `wp_subsurface` in + the trace), the browser itself converts NV12 → RGB in its + own GL context and hands KWin only RGB; KWin then composites + the RGB to its primary plane. +- **Under X11 without a compositor:** there is no separate + compositor process. Two paths are open to the client: + - *RGB-composite path* (browser converts NV12 → RGB in its + own GL context and presents the RGB result via XPresent/DRI3 + to the X server, which schedules a page-flip on the same + Primary plane KWin would have used). One fewer hand-off + than the Wayland-with-subsurface case but the same GL- + composite cost as the no-subsurface Wayland case. + - **Hardware-overlay path** (operator-supplied context + 2026-05-03: *"a X11 pipeline would route around that by + giving a portion of screen real estate directly to the + video pipeline"*). The X server allocates the Primary + plane (Plane 39, supports NV12 LINEAR) to the video + region and the Overlay plane (Plane 45, supports + RGB/AFBC) to the rest of the desktop. Hardware-blended + at scanout time. **No GL-composite of NV12 anywhere — + the cost the operator named as "the real bottleneck" + is structurally avoided.** -Until those are answered, Phase 0 documents the question space -and Phase 1 does not lock. +This second X11 path is what Wayland compositors as +designed today cannot do on rockchip-drm-class hardware: KWin +Wayland *must* own the Primary plane for its compositor +framebuffer (because the Wayland model is "compositor presents +one merged surface per output"), so it cannot give Plane 39 +to a video-region NV12 buffer while putting the rest of the +desktop on Plane 45. X11 + non-compositing WM has no such +constraint — different windows can be assigned to different +planes by the X server's plane allocator. + +This is the X11 hardware-overlay mechanism that historically +made X11 desktops good at video playback (Xv from the late +1990s, and the modern equivalents via DRI3 + XPresent + +Composite-redirection-disabled). It is structurally absent +in Wayland-with-monolithic-compositor designs. + +### Hypothesis the matrix tests + +There are three potentially separable costs: + +1. **The mandatory NV12 → RGB GL conversion**, which is + *forced* on Wayland-with-KWin because KWin must own the + only NV12-LINEAR-capable plane on this hardware for its + compositor framebuffer. **This cost is structurally + avoidable** under X11 + non-compositing WM via + hardware-plane-overlay (per the operator-supplied insight + above). Whether browsers can be coaxed to *use* the X11 + hardware-overlay path — rather than internally compositing + to RGB before presenting — is browser-specific (see Open + questions below). +2. **The fallback GL-composite cost** when the + hardware-overlay path doesn't engage. Both Wayland and X11 + pay this when the buffer shape doesn't match a plane — + it just runs in different processes (KWin under Wayland, + browser under X11). +3. **The per-frame compositor overhead** independent of NV12: + dmabuf import, transaction apply, presentation-feedback + wiring, frame-callback delivery — which the predecessor + measured at ~30-37 % of `kwin_wayland`'s CPU during + steady-state video playback even when KWin only saw RGB + surfaces. + +The X11 hypothesis is strongest if cost (1) is dominant on +the matrix's with-KWin cells AND the X11 cells trigger the +hardware-overlay path. The X11 hypothesis is weakest if +cost (1) is small and cost (3) is small — in which case the +"cutting out KWin" experiment would show only marginal +differences. + +The matrix below is designed to surface which of (1) (2) (3) +dominates per browser × decode path. + +"Faster video display" is operationally **a combination of**: + +- **Effective fps actually rendered** (= `getVideoPlaybackQuality().totalVideoFrames / elapsed_s` + for a 30 fps source — the upper bound is 30; the question is + how close). +- **Drop count** over the same 70 s window (`droppedVideoFrames`). +- **End-to-end latency** if testable (commit → present; + testable on Wayland via `wp_presentation_feedback`, + testable on X11 via `XPresent` extension or `RandR` vblank + events; protocol-side measurement under each + display-server). +- **Compositor + browser CPU at steady state** (the cost + saved by cutting the compositor is the upper bound on the + patch-payoff if a future campaign tries to optimise the + compositor instead of removing it). + +### Experimental matrix + +Six 2-axis cells (3 browsers × 2 decode paths) × 2 +session conditions (with-KWin / without-KWin): + +| Browser | 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 | + +The "(if it works)" / "where possible" qualifier per the +operator's directive: libva on rockchip-drm RK3568 only works +on chromium-fourier (Step 1 ports `libva-v4l2-request`); for +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. + +### What "cutting out the KWin compositor" means + +This campaign uses **X11 session with no compositor in the +display path** as the "without-KWin" cell. Specifically: + +- Native Xorg server, NOT XWayland (XWayland would still go + through KWin for display, defeating the purpose). +- Window manager that does NOT composite by default — e.g. + openbox, fluxbox, xfwm4-with-compositing-off, i3, twm. + Plasma X11 uses `kwin_x11` as compositing WM, which is + still a "KWin compositor" — it does not satisfy "cut KWin + out" and is **excluded** from the without-KWin cell. +- Browser windowed (not fullscreen). Even on a non-compositing + WM, fullscreen browsers may engage XPresent direct + presentation paths — testing windowed isolates the + baseline non-compositor windowed display path. + +The exact WM choice is a Phase 0 inventory decision (which +WMs are available on ohm, which install cleanly, which +SDDM-advertised sessions exist). Default candidate: openbox. + +### Three plausible outcome shapes + +- **(α)** Without-KWin is materially faster across all 6 + cells: confirms the KWin compositor cost is a real + bottleneck on this hardware, and X11-session-without- + compositor becomes the recommended daily-driver + configuration for video work on PineTab2. +- **(β)** Without-KWin is comparable or only marginally + faster: the compositor isn't the bottleneck; the drop + phenomenon is hardware/kernel/Mesa-bound, and the + predecessor's Phase 8 closure stands. +- **(γ)** Mixed picture per browser × decode path: e.g. + libva paths benefit but SW paths don't; or Firefox benefits + but chromium-class clients don't. Each cell becomes its own + characterisation. + +### Open questions before Phase 1 lock + +The hardware-overlay-path mechanism is structurally available +on X11 + non-compositing WM. Whether it actually engages for +each of the three browsers is browser-specific and currently +unknown: + +- **Brave / Chromium ozone-x11**: Chromium has overlay-support + code (`OverlayProcessor`, `GpuMemoryBufferManager`, + `DCOMPSurface` on Windows; on Linux X11 the path is via + XPresent + DMA-BUF + `OverlayCandidate`). Whether Brave + 147 / chromium-fourier 149 actually request hardware-overlay + presentation for a windowed video element under X11 is open. +- **Firefox**: VAAPIVideoDecoder backend produces hardware + decoded NV12 dmabufs that the GL compositor consumes + internally. Whether Firefox's X11 backend has a path to + hand the dmabuf to the X server for hardware-overlay + 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." + +If the operator agrees, Phase 0 inventory should: + +1. Verify Plane 39's NV12-LINEAR availability is reachable to + X11 clients (it is for KWin Wayland; should be for X11 too + since Plane 39 is just a DRM resource), and identify which + X11 path actually programs it (modesetting Xorg driver + + `Option "PageFlip" "true"`, or DRI3-presented buffer ending + up on Plane 39 via the X server's plane allocator). +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. + +### What this question does NOT cover + +For clarity, since the predecessor was specifically about +the Wayland-overlay-subsurface composite path: + +- This campaign is **not** investigating the wp_subsurface + route. The Wayland-cell of the matrix (with-KWin) measures + whatever browser configuration produces under the existing + Plasma Wayland session — windowed, default profile, default + flags. It's a measurement of the as-shipped Plasma Wayland + stack from the user's perspective, not a probe of a + specific KWin code path. +- The Δ_present-46 ms finding from the predecessor is + testable as a free side-finding under both axes (Wayland + and X11) but is not the campaign's primary question. +- Daily-driver fitness (apps that break under X11, touchscreen + behavior, multi-monitor edge cases, etc.) is **not in + scope**. The campaign's deliverable is the matrix above; if + any cell is decisively faster, daily-driver-fitness becomes + a follow-up campaign. ## What's NOT in scope (working assumption) diff --git a/worklist.md b/worklist.md index 0a0b36a..8ac0aaf 100644 --- a/worklist.md +++ b/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