The drm_info-during-playback probe under Wayland confirmed
KWin IS GL-compositing per frame: Plane 39 rotates triple-
buffered ABGR8888 framebuffers (FB IDs 60/61/66) during
playback. The earlier "0% kwin CPU = direct-scanout" reading
in a1_summary.md was a CPU-blind-spot artifact — Panfrost
shader work isn't visible to top or perf-on-userspace.
Corrigendum added to a1_summary.md preserving the original
text as the on-the-day record.
Worklist: A1 entry updated to point at both summaries.
The probe itself was invasive (drm_info every 3s perturbed
KWin's atomic-commit fast-path, kwin %CPU jumped 0->18 median
and 6 drops appeared) — usable diagnostically but cannot be
embedded in measurement reps.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 in-session reps of chromium-fourier 149 / brave_drops_test.html /
Plasma Wayland 6.6.4 (kwin-fourier 6.6.4-3 + qt6-base-fourier
6.11.0-3 carry-overs intact). Tight cluster IQR=0:
drops_total=0, drops_post_warmup=0, frames_total=1685, kwin %CPU
median=0.00, mean=0.04. Perf samples on kwin (~30 over 70s) show
zero composite/dmabuf/GL symbols — only event-loop bookkeeping.
Most likely mechanism: KWin direct-scanout fast-path engaged for
the single-visible-client video case. The campaign's load-bearing
hypothesis ("X11 + non-compositing WM avoids per-frame GL composite
of NV12") is structurally weakened — KWin already avoids that work
under Wayland for this workload. Phase 1 needs to add a
multi-window A1' variant and drm_info-during-playback to confirm
direct-scanout, then revisit matrix cell design.
revert.log entry 6: SDDM autologin + state.conf swap that landed
the Plasma Wayland session for the A1 reps. Backup of original
state.conf preserved at /var/lib/sddm/state.conf.x11-research-bak;
single-command revert documented.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Source-level verdict: no browser in the matrix has a code path
to hand NV12 to the X server for plane scanout. Chromium ozone-x11
wires StubOverlayManager (ozone_platform_x11.cc:262); Brave 147 +
chromium-fourier 149 inherit unchanged. Firefox WindowSurfaceX11
is RGB-only. The campaign's load-bearing hypothesis is structurally
weakened — what the X11 cells will measure for browsers is
KWin's per-frame RGB-recomposite cost, not the original
"force-GL-composite of NV12" framing. mpv --vo=xv becomes the
matrix's only direct test of the operator-supplied mechanism.
Matrix updated: 12 cells -> 16 cells (+8 mpv VO sub-points).
revert.log entries 1-5 capture all package + per-user state
mutations from this turn (measurement tools, openbox, XFCE +
xfwm4-no-comp pre-seed, firefox + AUR xtrace, XFCE rotation
+ touchscreen mapping); single SSH-driveable revert chain
returns ohm to its pre-campaign 1169-package state.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Live Plasma X11 session on ohm probed over SSH; substrate is
healthy (xorg-server 21.1.22 + Mesa 26.0.5 / Panfrost,
modesetting in-server, all 7 needed X protocol extensions live).
Evidence in phase0_evidence/x11_inventory_2026-05-03/ — five raw
captures + inventory.md summary. Worklist deliverables 2 + 4
flipped to done with operator-action checklist for the remaining
gating items (no non-compositing WM installed today; six
candidates one pacman -S away, openbox recommended).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
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) <noreply@anthropic.com>
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>
marfrit