Campaign closed 2026-05-03 with negative result on both axes
(X11+xfwm4-no-comp measurably worse than Plasma Wayland for
chromium-fourier on the test page; no client/path on this stack
engages hardware-overlay scanout for NV12). Full closing remarks
+ next-move options live at
dokuwiki.reauktion.de/doku.php?id=x11_session_research:start.
README left as the on-the-day framing for context; the new
status block points to the DokuWiki page as the
campaign-closure record. The Phase 0 evidence under
phase0_evidence/ is the source-of-truth substrate behind that
page.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Native X11 in XFCE / xfwm4-no-comp on tty7 / session 510.
Q1 (mechanism: does X server route NV12 to a hardware plane?):
NEGATIVE. Across 4 mpv VO × decode combinations
(--vo=xv ± hwdec, --vo=gpu ± hwdec), Plane 39 stayed XRGB8888
with FB ID 62 throughout. mpv-xv falls back to XShm software
put-image; mpv-gpu does GL composite via DRI3 + XPresent of an
RGB framebuffer; chromium-fourier-x11 same shape. No path on
this rockchip-drm + Mesa Panfrost + modesetting Xorg stack
engages hardware-overlay scanout for an NV12 client.
Q4 (browser X11 vs Wayland on same workload): the campaign
hypothesis is OPPOSITE to the data. chromium-fourier-x11 ×3
median: drops_post_warmup=9, frames_total=1532, fps=21.8.
Compare to A1 Wayland ×3 median: drops_post_warmup=0,
frames_total=1685, fps=24.04. X11 + xfwm4-no-comp is worse
than Plasma Wayland-with-KWin on every metric.
Likely cause: KWin's vblank-aligned wp_presentation_feedback
buffer scheduling absorbs client timing jitter; X11 + no
compositor exposes that jitter directly to the page's
getVideoPlaybackQuality() drop counter.
Operator subjective note: "first mpv was perfect" for
mpv-xv-sw despite mpv stderr "X11 can't keep up". 1080p24 SW
Xv is perceptually smooth on this hardware even though
instrumentation flagged it as struggling.
x1_summary.md surfaces three legitimate next moves: honest
closure, reframe to operator-experience-driven Wayland-stutter
scenarios, or pivot to client/driver-layer mechanism work
(modesetting NV12 Xv adapter, chromium hw-overlay flags).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two extended Wayland reps under increasingly aggressive
provocation conditions to find the stutter envelope referenced
in the campaign premise:
- a1prime_konsole_rep1: chromium-fourier + active konsole running
`top -d 0.5` behind, both at fullscreen-stacked geometry.
- a1prime_tiled_rep1: chromium-fourier at 600x400 tile +
konsole+top behind at fullscreen.
Both: drops_post_warmup=0, kwin %CPU median=0.00, perf zero
samples in composite/dmabuf/GL paths. Same floor result as
single-window A1.
KWin DBus scripting confirms the limitation: all top-level
windows are at fullscreen-equivalent geometry stacked, kwin's
z-order culls everything behind chrome from rendering. Even the
tiled rep didn't break the pattern.
Three interpretations: (A) predecessor's patches actually fixed
the original Wayland stutter on this workload (per
KWIN_PIVOT.md, plausible); (B) stutter conditions I haven't
matched (different content, time-of-session, load); (C) session-
state divergence. Cannot adjudicate from synthetic reps alone.
a1prime_findings.md surfaces four operator-decision options:
specific scenario from daily-driver, extended-use observation,
acceptance of (A) and matrix reframe, or continued probing.
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