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>
Spun off 2026-05-03 from the closed-without-patch
kwin_overlay_subsurface campaign (its phase8_handover.md is
the predecessor). The candidate research question is whether
running an X11 session on PineTab2 reproduces, eliminates, or
transforms the drop-inversion phenomenon that motivated the
predecessor — but the framing is provisional and awaits
operator confirmation before Phase 1 lock.
phase0_findings.md is the substrate doc:
- Predecessor close-out summary (three reasons no patch
landed; replicate-baseline-first lesson).
- What stays valid from the predecessor (Phase 1 scanout
archaeology, Phase 2-prime KWin Wayland source-read which
does NOT transfer to X11, Δ_present-46ms reproducible
side-finding which is directly testable under X11,
measurement infrastructure with WAYLAND_DEBUG-specific
parts that don't transfer).
- Current ohm state (carry-over predecessor tooling, governor
pin, baloo disabled, kwin-fourier still installed).
- Provisional research question with three plausible
outcomes (α/β/γ) and four alternate framings the operator
may have in mind that this question doesn't cover.
- Working-assumption out-of-scope list (no patches, no MRs,
no Δ_present chase yet).
- Four pre-question Phase 0 deliverables that are unblocked
regardless of framing: ohm state snapshot, X11-path
inventory, X11 measurement-tool inventory, A1
Wayland-baseline rep on this campaign's session for future
comparison anchor.
worklist.md tracks Phase 0 only. Phase 1 lock awaits the
research question. Discipline carry-overs from
kwin_overlay_subsurface listed (replicate baseline first;
phase discipline; non-upstreaming default; memory
persistence at close).
README.md status banner: Phase 0 in progress, research
question pending operator confirmation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit