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