Files

T

marfrit ac301b4e48 Phase 0: motivation locked + mechanism captured

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>

2026-05-03 06:49:18 +00:00

3.4 KiB

Raw Blame History

x11-session-research

Status: PHASE 0 — motivation locked 2026-05-03. See phase0_findings.md § "Research question (LOCKED 2026-05-03)". Phase 1 still requires the four pre-question Phase 0 deliverables (state snapshot, X11 path inventory, browser-overlay-path inventory, baseline anchor) before binding cells lock.

Research question: 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?

The operator-supplied mechanism: hantro decodes to NV12; rockchip-drm's overlay plane cannot accept NV12, so on Wayland KWin must own the only NV12-capable plane (Primary, Plane 39) for its compositor framebuffer, which forces a GL-composite of every NV12 video buffer. X11 + non-compositing WM can give the video region directly to Plane 39 (NV12 native) and put the rest of the desktop on Plane 45 (RGB AFBC), avoiding the forced GL-composite. The campaign's load-bearing hypothesis is that this plane-allocation freedom translates into measurable browser-video speedup.

The matrix is 3 browsers × 2 decode paths × 2 sessions = 12 cells (some N/A where libva isn't supported). See phase0_findings.md for the full table.

Predecessor

This campaign exists because ../kwin_overlay_subsurface/ closed 2026-05-03 without patch (phase8_handover.md). Its diagnostic loop terminated at "Phase 0 cage = 0 post-warmup drops floor not reproducible at N=3." The natural next move across the design surface is to vary the display server (X11 instead of Wayland) on the same hardware and the same client binary, but the operator has not yet confirmed that as the campaign's specific question.

Hardware target (provisional, same as predecessor)

ohm — PineTab2, Rockchip RK3568 (4× Cortex-A55, Mali-G52 MP2, hantro G1/G2 VPU). Kernel 6.19.10-danctnix1-1-pinetab2. Mesa 26.0.5. Currently runs KDE Plasma 6.6.4 Wayland.

For an X11-session campaign, ohm needs an Xorg + Plasma X11 (or similar X11 desktop) install path verified. As of 2026-05-03, the only confirmed display path on ohm is startplasma-wayland. Whether Plasma X11, an alternate X11 desktop (XFCE, openbox, lightweight WM), or Plasma running under a Wayland-Xorg shim is in scope is part of the research question to be locked.

Carry-overs from predecessor (still active on ohm)

Per kwin_overlay_subsurface/phase1_evidence/ohm_tooling_revert_log.md:

qt6-base-fourier 1:6.11.0-3 installed.
kwin-fourier 1:6.6.4-3 installed.
CPU governor pinned to performance (was conservative).
Baloo permanently disabled (Indexing-Enabled=false in ~/.config/baloofilerc).
drm-info 2.9.0-1 installed.

These were not reverted at the predecessor's close-out. This campaign inherits them unless an explicit revert is part of the design.

Non-upstreaming default

Inherited from the predecessor and from ohm_gl_fix. Bug reports + MRs are explicit operator-tasked decisions, not background process steps.

File map (will grow)

File	What it is
`README.md`	This file.
`phase0_findings.md`	Substrate from the predecessor + the candidate research question. Awaits operator confirmation/redirect on the question itself.
`worklist.md`	Phase-by-phase task list. Phase 0 only as of campaign start.

3.4 KiB Raw Blame History Unescape Escape