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>
84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
# x11-session-research
|
||
|
||
> **Status: PHASE 0 — motivation locked 2026-05-03.**
|
||
> See [`phase0_findings.md`](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/`](../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. |
|