# Phase 0 — substrate and provisional research question

This is the campaign's Phase 0 substrate doc: what we already
know from the predecessor `kwin_overlay_subsurface` close-out,
what's open, and what the candidate research question looks
like. **The research question is provisional and awaits
operator confirmation before Phase 1 lock.**

## Predecessor close-out summary

[`../kwin_overlay_subsurface/phase8_handover.md`](../kwin_overlay_subsurface/phase8_handover.md)
(closed 2026-05-03 without patch). Three independent reasons
no patch landed:

1. The campaign's locked Phase 1 reference floor
   (`drops_post_warmup == 0` from cage) is unreachable at N=3
   today. Today's median is 26 post-warmup with the same
   chromium-fourier binary, same hardware, same kernel, same
   Mesa, same kwin-fourier — KWin direct reproduces Phase 0's
   29 post-warmup, but cage now also drops ~22-56 post-warmup
   instead of Phase 0's 0.
2. The campaign's surface-of-investigation
   (`wp_subsurface` overlay route) is not engaged by
   `brave_drops_test.html`. Chromium-fourier renders the video
   element via internal compositing into its main browser
   window surface — a single-surface case.
3. The Phase 2 hot-path hypothesis
   (`glEGLImageTargetTexture2DOES` dominates `kwin_wayland`'s
   per-frame cost) was rejected by Phase 3 perf measurement
   with 100×-margin on the wrong side of the threshold.

The diagnostic loop terminated at "the campaign's premise was
N=1 to begin with, and the N=3 in-session re-measurement
doesn't replicate it." This is filed as a feedback memory:
*replicate the N=1 baseline at N=3 in the same session BEFORE
building multi-phase infrastructure around it*.

## What stays valid from the predecessor

Durable substrate listed in
`kwin_overlay_subsurface/phase8_handover.md` § "What's left
for a future session to pick up":

- **Phase 1 scanout-promotion archaeology** (rockchip-drm
  RK3568 plane format/modifier table, KWin v6.6.4 promotion
  predicate). Plane 39 (Primary, NV12 LINEAR) is the GL
  framebuffer; Plane 45 (Overlay) does not advertise NV12 in
  any modifier. Both KWin scanout-promotion paths are
  structurally rejected for windowed Brave on this DRM driver.
  This holds regardless of display server.
- **Phase 2 H1 file:line** in
  `kwin_overlay_subsurface/phase2_source_findings.md`. Cold
  per Phase 3 measurement; informational only.
- **Phase 2-prime Shape C source-read** of
  `Display::dispatchEvents` and `TransactionFence` in KWin's
  `src/wayland/`. Specific to the Wayland path; **not relevant
  to an X11-session campaign**. The X11 path uses different
  KWin surface plumbing (`kwin_x11`) and a different per-frame
  protocol (X11 Composite extension + Damage + XPresent), not
  Wayland protocol dispatch.
- **Δ_present-46 ms reproducible side-finding** under Plasma
  Wayland. Across all measured conditions (chromium-fourier on
  KWin, chromium-fourier in cage, stock Brave on KWin), median
  Δ_present was 41-46 ms on a 60 Hz panel — a stable
  ~2.7-vsync queue depth. This finding is independent of the
  cage breakdown and **directly testable under X11** as a
  comparison point.
- **Measurement infrastructure**:
  `kwin_overlay_subsurface/scripts/wayland_debug_to_csv.py`
  (libwayland 1.21+ format, 17 unit tests passing) +
  `phase3_prime_runs/run_browser.sh` orchestrator on ohm
  (handles `WAYLAND_DEBUG=1` capture, perf record, top
  sampling, drops trajectory extraction, kill-cleanly). **The
  WAYLAND_DEBUG portion does not apply under X11**; an X11
  equivalent would be different tooling (`xtrace`, `xev`, or
  XCB-debug instrumentation if the client emits any). The
  perf+top+drops capture portion remains usable under X11
  unchanged.

## Current ohm state (carry-over from predecessor)

Per `kwin_overlay_subsurface/phase1_evidence/ohm_tooling_revert_log.md`,
not reverted at predecessor close-out:

- `qt6-base-fourier 1:6.11.0-3`
- `kwin-fourier 1:6.6.4-3` (Wayland-side compositor; not in
  the hot path under an X11 session)
- `mesa 1:26.0.5-1`
- CPU governor pinned to `performance`
- Baloo permanently disabled
- `drm-info 2.9.0-1`
- Active session: `startplasma-wayland` on tty2,
  `kwin_wayland` PID 3927 (as of 2026-05-03 03:05 UTC).
- Browser binaries available: `/tmp/chromium-ohm-gl-fix-step2/chrome`
  (chromium-fourier, Step 1 + Step 2 patches, 149.0.7812.0),
  `/usr/bin/brave` (`brave-bin 1:1.89.145-1`).

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)

**Candidate framing**, not locked:

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

This is the most narrowly relevant question given the
predecessor's close-out. Three plausible outcomes:

- **(α)** 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."

**Alternate framings** the operator may have in mind that
this provisional question doesn't cover:

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

**Operator decision needed before Phase 1**:

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).

Until those are answered, Phase 0 documents the question space
and Phase 1 does not lock.

## What's NOT in scope (working assumption)

Until the research question is confirmed, the following are
treated as out of scope so they don't slip into Phase 1
prematurely:

- Patches to KWin, Xorg, kwin-fourier, qt6-base-fourier, or any
  other component on ohm. This is **research**, not
  patch-development. Per non-upstreaming default, MR/bug-report
  filing is explicitly tasked and not scheduled here.
- The Δ_present-46 ms finding's investigation. It's a known
  hook from the predecessor; whether this campaign chases it
  depends on the locked research question.
- Reverting predecessor tooling state. Governor, baloo,
  `qt6-base-fourier`, `kwin-fourier` stay as-is unless the
  operator decides otherwise.
- File a bug for any of the predecessor's three documented
  candidate findings. Same non-upstreaming default applies.

## What Phase 0 will deliver, regardless of framing

Even before the research question is locked, the following are
useful Phase 0 deliverables that don't depend on the specific
question:

1. **State snapshot of ohm under current Plasma Wayland**
   captured at campaign start. This is the *before* photo for
   any future X11 vs Wayland comparison. Unattended-tractable
   (just scripted SSH).
2. **Inventory of available X11 paths on ohm**: what packages
   are installed, what session candidates SDDM advertises,
   what would need to be installed to enable a Plasma X11
   session, what alternate WMs are available. Read-only,
   unattended-tractable.
3. **Inventory of measurement instruments that work under
   X11**: `xtrace`, `xprop`, `xrandr --verbose --query`, perf
   on `Xorg` PID, frame-timing extraction options. Read-only.
4. **A1 baseline** under current Plasma Wayland: re-run a
   single rep of the predecessor's `kwin_timing_nodebug`
   condition immediately at the start of this campaign, so
   the comparison Wayland-vs-X11 has a same-session anchor.
   This is the "set the baseline before instrument changes"
   discipline from `feedback_replicate_baseline_first.md`.

These steps are unblocked. They don't commit to a specific
research question and they produce evidence that's useful
under any of the candidate framings.