marfrit
ac301b4e48
Operator-supplied research question 2026-05-03: "Does cutting out the KWin compositor enable faster video display of Brave, chromium-fourier, and Firefox — for full SW decoding, and for libva decoding (where possible) — on PineTab2 RK3568?" Operator-supplied mechanism 2026-05-03 (two messages): 1. "hantro emits NV12 which the GPU can't put on a compositeable plane. So that is the real bottleneck of Wayland." Connects directly to predecessor's Phase 1 finding (kwin_overlay_subsurface/phase2_source_findings.md:170-229): rockchip-drm overlay Plane 45 advertises no NV12 modifier; Primary Plane 39 supports NV12 LINEAR but is owned by KWin for its compositor framebuffer. Predecessor named the constraint but not the consequence — the consequence is that NV12 → RGB GL-composite is forced on Wayland-with-KWin regardless of which protocol path the browser uses. 2. "A X11 pipeline would route around that by giving a portion of screen real estate directly to the video pipeline." The X11 hardware-overlay path: with X11 + non-compositing WM, the X server can allocate Plane 39 (NV12 LINEAR) to the video region and Plane 45 (RGB AFBC) to the rest of the desktop. Hardware-blended at scanout. NO GL-composite anywhere — the cost the operator named as "the real bottleneck" is structurally avoided. This is the X11 hardware-overlay mechanism that historically made X11 desktops good at video playback (Xv → modern DRI3 + XPresent + Composite-redirection-disabled). Wayland-with-monolithic-compositor designs cannot use this freedom: the compositor must own the Primary plane, so the plane-allocation freedom required to put NV12 video on Plane 39 alongside RGB chrome on Plane 45 isn't available. phase0_findings.md updated with: - Locked research question + 12-cell experimental matrix (3 browsers × 2 decode paths × 2 sessions; some N/A). - Three separable cost components the matrix tests for (mandatory NV12→RGB GL conversion if hardware-overlay doesn't engage, fallback GL-composite, per-frame compositor overhead independent of NV12). - Open questions about whether browsers actually request hardware-overlay presentation under X11, or whether they always internally composite to RGB. - Recommendation to add mpv as a reference X11-overlay client: distinguishes "X11 path works on this hardware" from "browsers actually use the X11 path." worklist.md updated: - Phase 0 motivation + matrix items ticked. - Pre-Phase-1 inventory broken out: state snapshot, X11 path inventory, browser-overlay-path inventory, mpv reference, X11 measurement-tool inventory, A1 Wayland baseline anchor. - Phase 1 sketch: binding cells per matrix cell, clear-pass / clear-fail thresholds, measurement protocol mirroring the predecessor's phase3_protocol.md structure. README banner updated to reflect locked motivation + mechanism summary + matrix shape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.2 KiB
5.2 KiB
Work items — x11-session-research
Phase 0 — substrate + research question + inventory
Status: IN PROGRESS. Motivation LOCKED 2026-05-03 in
phase0_findings.md § "Research question". Pre-Phase-1
inventory and baseline-anchor work below.
- Predecessor close-out summarised. Substrate doc lists
what transfers from
kwin_overlay_subsurfaceand what's Wayland-specific (KWin source-reads don't transfer to X11 path). - Research question locked. "Does cutting out the KWin compositor enable faster video display of Brave, chromium-fourier, and Firefox — for full SW decoding, and for libva decoding (where possible) — on PineTab2 RK3568?"
- Mechanism captured. Operator-supplied insight 2026-05-03: hantro emits NV12, rockchip-drm overlay plane doesn't accept NV12, so KWin must own the only NV12-capable plane (Primary, Plane 39) and forces GL-composite of every NV12 buffer. X11 + non-compositing WM can give the video region directly to Plane 39 and put rest of desktop on Plane 45 (RGB AFBC) — hardware-blended, no GL-composite.
- Experimental matrix drafted. 3 browsers × 2 decode
paths × 2 sessions = 12 cells (some N/A where libva isn't
supported). See
phase0_findings.md§ "Experimental matrix". - State snapshot of ohm under current Plasma Wayland — the campaign-start before photo. Unattended-tractable via SSH. Captures package versions, kernel, kwin_wayland PID + cmdline, governor, services, browser binary versions, test asset paths, thermal_zone temps.
- Inventory of available X11 paths on ohm:
- Installed packages:
xorg-server,xorg-xinit,xorg-xrandr, drm/dri stack,mesa-x11if separated. - SDDM-advertised sessions: list
/usr/share/xsessions/*. - Alternate WMs available (openbox, fluxbox, xfwm4, i3, etc.) — what's installed, what'd need installing.
- Whether modesetting Xorg driver (
xf86-video-modesetting) is the active driver path on rockchip-drm, vs an older armsoc/fbdev driver. - XWayland availability and version (relevant only as a third comparison axis — primary X11 cells are NATIVE Xorg, not XWayland).
- Installed packages:
- NEW: Browser X11-overlay-path inventory. Per
phase0_findings.md§ "Open questions": determine whether Brave 147 ozone-x11, chromium-fourier 149 ozone-x11, and Firefox X11 backends actually request hardware-overlay presentation for windowed video, or whether they always internally composite to RGB. Browser-specific source-grep- chrome trace inspection.
- NEW: Add mpv as a reference X11-overlay client.
mpv with
--vo=xvor--vo=gpu --gpu-context=x11is a known-good X11 hardware-overlay path. Adding mpv to the matrix as a 4th client provides "is the X11 hardware-overlay path even reachable on this hardware" baseline, separate from "do browsers use it." If mpv hits Plane 39 NV12 cleanly but browsers don't, the answer is "X11 path is fast, but the browsers don't take advantage of it." - Inventory of X11-side measurement instruments. Available
options:
xtrace(X protocol tracer),xev(event viewer),xprop(window properties),xrandr --verbose(output state),glxinfo,compton-transfor compositor detection, perf on Xorg PID. Frame-timing under X11 typically usesXPresentnotify events orINTEL_swap_eventGLX extension equivalents — what's available on rockchip is open. - A1 baseline: Wayland-with-KWin reference rep.
1×
kwin_timing_nodebug-equivalent run on current Plasma Wayland session captured intophase0_evidence/wayland_baseline_rep1/as the same-session anchor for the cross-session Wayland-vs-X11 comparison. Perfeedback_replicate_baseline_first.md.
Phase 1 — binding cells + measurement protocol
Pending Phase 0 inventory + A1 baseline anchor. Phase 1
lock will produce phase1_lock.md with:
- Binding cells per matrix cell (effective_fps, drops_total, drops_post_warmup, end-to-end-latency-if-testable, compositor+browser CPU at steady state).
- The clear-pass / clear-fail thresholds: what "X11 is faster" means quantitatively. Provisional: a matrix cell counts as "X11 faster" if effective_fps under X11 is ≥ 28 (out of 30 source) AND drops_post_warmup is ≤ 5, on a same-session cross-paired comparison with the corresponding Wayland cell.
- The measurement protocol per matrix cell, including how the
X11 sessions are entered and how the browser is launched
with libva forced on/off. Mirrors the structure of
kwin_overlay_subsurface/phase3_protocol.md.
Phase 2-onwards
Pending.
Discipline carry-overs from kwin_overlay_subsurface
- Replicate the baseline first — per
feedback_replicate_baseline_first.md. Phase 0 task "A1 baseline" exists specifically because of this lesson; do not skip it. - Phase discipline — no patches before source-read is documented. Re-scoping must be honest about deferral target.
- Non-upstreaming default — bug reports + MRs are explicit operator-tasked decisions.
- Memory persistence rule — when this campaign reaches its
diagnostic terminal state (success or honest closure), update
project_campaign_overview.mdand add any new feedback memory worth carrying forward to the next campaign.