x11-session-research/phase0_evidence/wayland_baseline_2026-05-03/a1prime_findings.md

A1' multi-window probe — findings + open question for operator

Date: 2026-05-03 14:23 → 16:18 CEST. Goal: provoke Wayland-side stutter under multi-window conditions, so the matrix has a non-floor Wayland baseline for the X11 cells to compare against. Outcome: could not provoke stutter under any condition tested in 5 reps. All show drops_post_warmup = 0 and kwin %CPU median = 0.00 — same floor result as the single-window A1.

Reps run

Rep	Condition	drops_total	drops_post_warmup	frames_total	kwin %CPU median
a1_rep1	single-window chromium-fourier-kwin	0	0	1685	0.00
a1_rep2	single-window chromium-fourier-kwin	0	0	1685	0.00
a1_rep3	single-window chromium-fourier-kwin	0	0	1686	0.00
a1prime_konsole_rep1	chromium-fourier + active konsole+top behind, both fullscreen-stacked	0	0	1687	0.00
a1prime_tiled_rep1	chromium-fourier at 600×400 tile + konsole+top behind at fullscreen	1	0	1682	0.00

What I learned about Wayland's window state

Probed via a kwin script (org.kde.KWin /Scripting) that called workspace.windowList() and printed each window's resourceClass + caption + geometry + minimized/hidden state. During the "multi-window with active konsole" rep, the window list was:

plasmashell || hidden=false geometry=0,0,1280×800        (desktop wallpaper)
plasmashell || hidden=true  geometry=0,738,1280×62        (panel — auto-hidden)
kwin_wayland|| hidden=false geometry=0,0,1280×800        (kwin internal)
org.kde.konsole|~ : bash — Konsole | hidden=false geometry=0,0,1280×800
org.kde.konsole|~ : top — Konsole  | hidden=false geometry=0,0,1280×800

Multiple top-level windows exist, all at fullscreen-equivalent geometry stacked on top of each other. hidden=false reports that none are minimized — but the kwin compositor's z-order hides windows-behind-windows from rendering. Only the topmost visible client (chrome, when it's launched) is being painted. The active konsole's text scrolling never reaches kwin's composite stage because the konsole is occluded by chrome.

The tiled rep tried to fix this: chrome at 600×400+350+150, konsole at fullscreen behind. Even there, drops_post_warmup = 0 and kwin %CPU = 0. Either the tiled chrome triggered some other fast-path (maybe both planes engaged: chrome's NV12 to Plane 39, konsole+desktop's RGB to Plane 45), or the konsole was still mostly occluded by Plasma's desktop background painting between its window decoration and the chrome viewport.

perf reports across all 5 reps

Top symbols on kwin_wayland for the 5 reps:

rep	top symbol(s) — % of (sparse) samples
a1_rep1	__pi_memcpy_generic 97 % (single big memcpy in 39 samples)
a1_rep2	libz.so 38 %, call_filldir 32 %
a1_rep3	dbus_message_unref 39 %, QUnixEventDispatcherQPA::processEvents 37 %, libz 23 %
a1prime_konsole_rep1	(similar shape — DBus + Qt event loop + libz)
a1prime_tiled_rep1	(similar shape)

Zero samples in any composite/dmabuf-import/GL path across all 5 reps. Total cycle counts in the millions, not billions. KWin was scheduled out for >99 % of every 70 s capture window.

Two interpretations

(A) The predecessor's patches (kwin-fourier 6.6.4-3 + qt6-base-fourier 6.11.0-3 + chromium-fourier 149) actually fixed the Wayland-stutter problem the campaign is named after. The predecessor's KWIN_PIVOT.md documents exactly this success on 2026-04-28: "Three patches landed on ohm in sequence ... Together they produce smooth 1080p30 H.264 playback under KDE Plasma 6.6.4 Wayland on the box where stock chromium previously stalled in 3 seconds." The drops the predecessor measured later (kwin_timing_nodebug_rep[1-3]: 14, 28, 42 drops_post_warmup) may have been residual variance that has since settled out, or captured during a transient state.

(B) I haven't found the right conditions. The user's operating premise was that Wayland stutter is observable in their daily-driver use. My 70s synthetic reps haven't reproduced what the user has observed. Possibilities:

• Different content (YouTube, not local file; specific codecs)
• Different decode path (libva engaging vs not)
• Time-of-session (cumulative state after hours of use)
• System concurrency (other apps doing real work)
• Power state (battery vs charging, governor transitions)
• Page-specific behavior (sites that engage HDR, advertising, WebRTC, etc.)

I cannot tell from synthetic reps alone whether (A) or (B) holds.

Question for operator

To honor the campaign idea ("stutterless playback - possible with X11? proven impossible with Wayland") without circumventing it into a different question, I need a decisive scenario from your daily-driver experience. Options ordered by my preference:

1. A specific URL or video file + viewer + duration that you personally observe stuttering under Wayland on this PineTab2. I'll replicate that exact scenario across the matrix cells. E.g.: "play https://www.youtube.com/watch?v=… in Brave fullscreen for 2 minutes, by minute 1 you'll see drops."

2. An extended-use observation protocol. Run a passive monitor daemon (logs frame-drops, kwin-CPU events, page-faults) for an hour during your normal Wayland use; then the same hour under X11. Compare. Less synthetic, more honest about what "your daily-driver experience" actually involves.

3. Confirmation of (A). If you accept that the kwin-fourier patches fixed the original Wayland-stutter problem on the 24fps test page, the campaign's premise on this specific workload is no longer valid and the matrix should reframe around either a harder workload (1080p60, 4K, network video) where stutter still happens, OR around a different question (latency, power, daily-driver-quality-of-life) where X11 vs Wayland may still differ even when both deliver clean playback.

4. Continue probing. I haven't yet tested: stock Brave 147 (script support gap — would need a small wrapper), Firefox 150 (no script support at all), longer captures (e.g. 10 min instead of 70 s), thermal-stressed conditions (run yes > /dev/null on three cores in parallel), battery-drain mode (if PineTab2's governor changes when unplugged). These extend the search space but risk becoming data-shopping if pursued without a specific operator-observed condition to match.

The honest report is: under conditions I can synthesize from SSH in a freshly-autologin'd Plasma Wayland session on this hardware right now, Wayland is delivering stutterless playback on brave_drops_test.html. Anything I'd do beyond this without operator guidance risks tuning conditions until drops appear, which is exactly the data-shopping the campaign-contained-data discipline guards against.

File map

a1prime_konsole_rep1/  — chrome + active konsole+top behind, both fullscreen-stacked
a1prime_tiled_rep1/    — chrome at 600x400, konsole+top behind at fullscreen
a1prime_findings.md    — this file

Each rep dir has the same shape as a1_rep[1-3]/ (15 files; top_full.txt and stderr.log are in .gitignore).