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