# 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`).