x11-session-research/phase0_evidence/x11_baseline_2026-05-03/x1_summary.md

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.