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>
111 lines
5.2 KiB
Markdown
111 lines
5.2 KiB
Markdown
# 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.
|
||
|
||
- [x] Predecessor close-out summarised. Substrate doc lists
|
||
what transfers from `kwin_overlay_subsurface` and what's
|
||
Wayland-specific (KWin source-reads don't transfer to X11
|
||
path).
|
||
- [x] **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?"
|
||
- [x] **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.
|
||
- [x] **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-x11` if 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).
|
||
- [ ] **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=xv` or `--vo=gpu --gpu-context=x11` is 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-trans` for compositor detection,
|
||
perf on Xorg PID. Frame-timing under X11 typically uses
|
||
`XPresent` notify events or `INTEL_swap_event` GLX
|
||
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 into
|
||
`phase0_evidence/wayland_baseline_rep1/` as the
|
||
same-session anchor for the cross-session
|
||
Wayland-vs-X11 comparison. Per
|
||
`feedback_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.md` and add any new feedback
|
||
memory worth carrying forward to the next campaign.
|