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>
marfrit