Phase 0: campaign skeleton, research question pending
Spun off 2026-05-03 from the closed-without-patch kwin_overlay_subsurface campaign (its phase8_handover.md is the predecessor). The candidate research question is whether running an X11 session on PineTab2 reproduces, eliminates, or transforms the drop-inversion phenomenon that motivated the predecessor — but the framing is provisional and awaits operator confirmation before Phase 1 lock. phase0_findings.md is the substrate doc: - Predecessor close-out summary (three reasons no patch landed; replicate-baseline-first lesson). - What stays valid from the predecessor (Phase 1 scanout archaeology, Phase 2-prime KWin Wayland source-read which does NOT transfer to X11, Δ_present-46ms reproducible side-finding which is directly testable under X11, measurement infrastructure with WAYLAND_DEBUG-specific parts that don't transfer). - Current ohm state (carry-over predecessor tooling, governor pin, baloo disabled, kwin-fourier still installed). - Provisional research question with three plausible outcomes (α/β/γ) and four alternate framings the operator may have in mind that this question doesn't cover. - Working-assumption out-of-scope list (no patches, no MRs, no Δ_present chase yet). - Four pre-question Phase 0 deliverables that are unblocked regardless of framing: ohm state snapshot, X11-path inventory, X11 measurement-tool inventory, A1 Wayland-baseline rep on this campaign's session for future comparison anchor. worklist.md tracks Phase 0 only. Phase 1 lock awaits the research question. Discipline carry-overs from kwin_overlay_subsurface listed (replicate baseline first; phase discipline; non-upstreaming default; memory persistence at close). README.md status banner: Phase 0 in progress, research question pending operator confirmation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,213 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user