x11-session-research/phase0_findings.md

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