# Phase 0 X1 — X11 / xfwm4-no-comp baseline + mpv mechanism probes **Date:** 2026-05-03 ~20:17–20:43 CEST. **Session:** XFCE on tty7 / session 510, xfwm4 with `use_compositing=false` (entry-2 pre-seed). Native X11 — Xorg PID 45263, modesetting Xorg driver, DSI-1 1280×800 @ 59.98 Hz with `right` rotation. **Workload:** 1080p **24 fps** H.264 (`bbb_1080p30_h264.mp4` — file is misnamed; mpv reports 24 fps content) for mpv reps; `brave_drops_test.html` for chromium reps (matches A1 Wayland reps exactly). ## Headline results **Q1 (campaign mechanism — does the X server route NV12 to a hardware plane?): NEGATIVE.** Across 4 mpv VO × decode combinations, **Plane 39 stayed XRGB8888 with FB ID 62 the entire time.** No path under native X11 + modesetting Xorg + Mesa Panfrost engages hardware-overlay scanout on this rockchip-drm RK3568 stack. | Cell | Plane 39 pre | Plane 39 post | mpv stderr indicator | |---|---|---|---| | mpv `--vo=xv --hwdec=no` | XRGB8888 / fb 62 | XRGB8888 / fb 62 | "X11 can't keep up! XShm completion events" | | mpv `--vo=xv --hwdec=v4l2request-copy` | XRGB8888 / fb 62 | XRGB8888 / fb 62 | autoconvert `nv12 → yuv420p`, A/V desync | | mpv `--vo=gpu --gpu-context=x11 --hwdec=no` | XRGB8888 / fb 62 | XRGB8888 / fb 62 | clean exit, VO yuv420p | | mpv `--vo=gpu --gpu-context=x11 --hwdec=v4l2request-copy` | XRGB8888 / fb 62 | XRGB8888 / fb 62 | clean exit, **VO accepted nv12 directly** | Plane 45 stayed at FB 0 (unused) throughout. **Q4 (browser X11 vs Wayland comparison on the same workload): NEGATIVE for the campaign hypothesis.** chromium-fourier under native X11 + xfwm4-no-comp produces **more** drops, **fewer** frames, **lower** effective fps than the same browser on the same page under Plasma Wayland 6.6.4 with KWin compositing. | | chromium-fourier-x11 (n=3) | A1 Wayland (n=3) | |---|---|---| | drops_total median | **14** | 0 | | drops_post_warmup median | **9** | 0 | | frames_total median | **1532** | 1685 | | effective fps median | **21.8** | 24.04 | A 3-rep cluster doesn't have IQR vs IQR comparison meaningful for floor-vs-non-floor, but the difference is 9 drops_post_warmup vs 0, sustained, with the X11 cells consistently below the Wayland baseline on every metric. **This is the opposite of the campaign hypothesis.** ## Operator subjective observation **"first mpv was perfect"** — operator-reported during the mpv-xv-sw rep (the one where mpv stderr complained "X11 can't keep up"). The visible playback was smooth even though Plane 39 stayed XRGB8888 (no hardware overlay) and mpv was using 101 % of one CPU core for SW XShm put-image at 1080p24. **A subjective data point that a software-Xv path can deliver perceptually stutterless 1080p24 playback** on this hardware, regardless of the absence of hardware-overlay scanout. ## Per-cell details ### mpv-xv-sw (`--vo=xv --hwdec=no`) ``` VO: [xv] 1920x1080 yuv420p [vo/xv] X11 can't keep up! Waiting for XShm completion events... GPU: 487 MHz mean (98.6% non-idle) Workload CPU: 101% mean, 186% peak Plane 39: XRGB8888 fb 62 throughout ``` Xv adapter on modesetting Xorg + rockchip-drm uses **XShm software put-image**. mpv decodes H.264 → yuv420p in software on a single core, hands the YUV image to the X server via shared memory; the X server CPU-converts YUV → RGB and draws into the screen pixmap (Plane 39's FB 62). No hardware-overlay path engaged. Despite mpv's "can't keep up" warning, **operator subjectively observed smooth playback**. ### mpv-xv-hw (`--vo=xv --hwdec=v4l2request-copy`) libva via `libva-v4l2-request-fourier` decodes H.264 → NV12 on the hantro VPU. mpv autoconverts NV12 → yuv420p (since Xv only accepts yuv420p) — that conversion is the bottleneck. ``` [autoconvert] Converting nv12 -> yuv420p VO: [xv] 1920x1080 yuv420p Audio/Video desynchronisation detected! Consider trying `--profile=fast` and/or `--hwdec=auto` as they may help. ``` The `--hwdec=v4l2request-copy` path doesn't help under Xv because the autoconvert eats more CPU than software decode saved. **A/V desync is the canonical mpv stutter signal.** ### mpv-gpu-sw (`--vo=gpu --gpu-context=x11 --hwdec=no`) ``` VO: [gpu] 1920x1080 yuv420p GPU: 800 MHz median, 774 MHz mean (96.4% non-idle) Plane 39: XRGB8888 fb 62 throughout ``` mpv's modern GPU VO does GL composite (libplacebo shaders) with DRI3 + XPresent. GPU runs near max (Mali-G52 at full 800 MHz). No hardware overlay; mpv presents an RGB framebuffer that the X server scans out from Plane 39. ### mpv-gpu-hw (`--vo=gpu --gpu-context=x11 --hwdec=v4l2request-copy`) ``` VO: [gpu] 1920x1080 nv12 GPU: 800 MHz median, 777 MHz mean (98.6% non-idle) Plane 39: XRGB8888 fb 62 throughout ``` Same as mpv-gpu-sw but with hardware decode producing NV12 that mpv's GL VO accepts directly (no CPU autoconvert). GPU shader handles NV12 → RGB sampling. Still no hardware-overlay scanout — mpv's RGB output goes to FB 62. ### chromium-fourier-x11 ×3 ``` chromium-ohm-gl-fix-step2/chrome --enable-logging=stderr --autoplay-policy=no-user-gesture-required --user-data-dir=/tmp/chrome-profile-... file:///home/mfritsche/fourier-test/brave_drops_test.html ``` Note: chromium ozone defaults to X11 backend when no `--ozone-platform=` is specified and `WAYLAND_DISPLAY` is unset (under XFCE/X11, it isn't). The "Failed to send GetTerminationStatus" stderr noise is teardown-only. Three reps. Frame-by-frame DROPS_TRAJECTORY shows drops are NOT clumped — they trickle throughout the playback at ~0.1–0.4 per second, accelerating slightly toward the end. This is qualitatively different from "stall, recover, stall" patterns; it's persistent low-grade frame loss. ## Why is X11 worse than Wayland here? A reasonable hypothesis: under Plasma Wayland, KWin's **triple-buffered GL composite path is engineered with explicit vblank-aligned commit timing** via `wp_presentation_feedback`. The browser hands KWin a buffer once per browser-frame; KWin schedules its own composite at vblank. Drops require both the browser missing its compose deadline AND KWin missing the next vblank — a more robust double-buffer than X11's single-buffer scanout. Under native X11 + xfwm4-no-comp: - xfwm4 isn't compositing (use_compositing=false), so it has zero buffer-management role - Chromium's ozone-x11 backend presents directly via DRI3 + XPresent - The X server schedules the present, but **the client (chrome) is the only buffer-flow manager** — there's no intermediate compositor to absorb timing jitter - Result: when chrome's GPU process misses its target, no buffer-of-last-resort exists; the X server scans out the previous fb again, which the page-level `getVideoPlaybackQuality()` counts as a drop This is **the opposite of the campaign's "no compositor = fewer drops" reasoning**, and well-documented as a known property of compositorless X11 + DRI3: less smoothing, more client-visible jitter. ## What the data does NOT establish - That this result generalizes to other workloads. Operator reported *subjectively* perfect playback for mpv-xv-sw — the "stutter" observation is specific to chrome on this test page. - That all native-X11 + non-comp WM combos behave like xfwm4-no-comp. openbox might have different buffer-flow characteristics; not tested in this session. - That a Plasma Wayland session under stress (multi-window with continuously-updating surfaces, GPU contention, thermal throttling) wouldn't ALSO stutter. The campaign's premise is operator's observed daily-driver experience — my synthetic 70 s reps in a fresh Wayland session don't cover the conditions where Wayland actually fails. - That hardware-overlay support is *impossible* on this stack. modesetting Xorg with `Option "PageFlip" "true"` and a video driver explicitly requesting DRM_FORMAT_NV12 scanout might engage Plane 39 NV12 — but that path isn't wired in any of the clients we tested. **It's a kernel / Mesa / Xorg-driver gap, not a hardware gap.** ## Implications for the campaign The original framing — *"stutterless playback possible with X11? proven impossible with Wayland"* — is **partially inverted by today's data on this specific workload**: - Wayland is delivering stutterless playback (A1 reps: 0 drops × 3). - X11 + non-compositing WM is **not** delivering stutterless playback (X1 reps: 9 drops_post_warmup median). The campaign's load-bearing mechanism — "X11 can give Plane 39 directly to NV12" — is also not realized on this stack (mpv reps × 4 confirm Plane 39 stays XRGB8888 regardless of client). This is a **decisive negative outcome for the campaign as originally framed**. Three legitimate next moves: 1. **Honest closure.** Document the negative result as the research outcome. The campaign answers "no, X11 doesn't help here, and no, the predicted mechanism isn't engaged on this hardware/software stack." That is itself a useful research finding — particularly for anyone considering X11 as a Wayland-stutter workaround on rockchip-drm. 2. **Reframe to find the conditions under which Wayland actually stutters.** Operator-experience driven: specific apps/content/durations that reproduce the daily-driver stutter, then test those same conditions under X11. Risks data-shopping; needs operator-supplied scenarios to anchor against. 3. **Pivot the mechanism question.** If the X server isn't programming Plane 39 with NV12 because no client requests it, the lever is at the client/driver layer, not the session layer. Investigate: would patching the modesetting Xorg DDX driver to expose an NV12-capable Xv adapter change the result? Would `--ozone-platform=x11` with chromium's `--enable-features=...` for hardware video overlay change the result? These are kernel/Mesa/X-driver patches, not user-facing-session changes. ## File map ``` 01_live_session.txt — XFCE/X11 substrate snapshot x11research_x1_mpv_xv_sw/ — mpv --vo=xv --hwdec=no x11research_x1_mpv_xv_hw/ — mpv --vo=xv --hwdec=v4l2request (incomplete, SSH-killed) x11research_x1_mpv_xv_hw_rep1/ — same, retried clean via systemd-run x11research_x1_mpv_gpu_sw/ — mpv --vo=gpu --hwdec=no x11research_x1_mpv_gpu_hw/ — mpv --vo=gpu --hwdec=v4l2request x11research_x1_chromium_fourier_x11/ — chromium-fourier 1st rep (drops 37 — outlier) x11research_x1_chromium_fourier_x11_rep1/ — chromium-fourier 2nd rep (drops 14) x11research_x1_chromium_fourier_x11_rep2/ — chromium-fourier 3rd rep (drops 11) x1_summary.md — this file ``` Each rep dir contains `drops_summary.txt` (where applicable), `gpu_freq_summary.txt`, `drm_diff.txt`, `top_workload.txt`, `top_full.txt`, `stderr.log`, `perf_report_top50.txt`, and the raw devfreq trans_stat / drm_info dumps.