From 067a221bc69a3fbee97838f2cf98693dbd683c5b Mon Sep 17 00:00:00 2001 From: claude-noether Date: Tue, 5 May 2026 18:16:59 +0000 Subject: [PATCH] README: add TL;DR explaining libva, firefox-fourier, sister campaigns TL;DR section at the top covers: - What libva is (standard userspace shim, backends per hardware, what v4l2_request is in this lineage) - Why firefox-fourier exists (Firefox 150 RDD sandbox blocks /dev/media* + linux/media.h ioctls; the ~50-line patch opens just what V4L2-stateless decoders need) - Sister fourier-series campaigns: kwin-fourier (compositor / scanout-plane fixes) + chromium-fourier (Chromium VAAPI on aarch64 + GL-stack workarounds for Mali-G52/Panfrost) Skim-friendly intro for new readers; the rest of the README stays the campaign-discipline detail. Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index b1ad322..32d92a7 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,17 @@ # libva-multiplanar +## TL;DR + +**libva** (= "Linux Video Acceleration API") is the standard userspace shim that lets video apps — Firefox, Chromium, mpv, GStreamer, vlc — talk to GPU/VPU hardware decoders without per-vendor code. Apps call libva; libva loads a backend driver (`.so` in `/usr/lib/dri/`) for the local hardware. Common backends: `intel-iHD` (Intel iGPUs), `mesa-va-gallium` (AMD), `nvidia-vaapi-driver`, and **`v4l2_request`** for V4L2-stateless ARM/embedded decoders (Rockchip hantro, Allwinner cedrus, Sun*, etc.). This campaign hardens a fork of the v4l2-request backend to actually work on Rockchip hantro (PineTab2 RK3568 first), end-to-end, for real consumers. + +**`firefox-fourier`** ([build instructions](firefox-fourier/README.md)) exists because Firefox 150's RDD-process sandbox blocks two things V4L2-stateless decoders need: `/dev/media*` request-API nodes (broker policy never lists them) and `linux/media.h` ioctls (seccomp policy doesn't admit magic byte `'|'`). Stock Firefox on hantro/cedrus/sun* hardware therefore SW-decodes everything unless you set `MOZ_DISABLE_RDD_SANDBOX=1` (which turns the whole sandbox off). The `firefox-fourier` patch — ~50 lines across two files — opens *just* what V4L2-stateless decoders need, sandbox stays on. Tested working with the iter5-end libva backend. + +**Sister campaigns** in the operator's "fourier" series — same hardware, different layers of the pipeline: +- [`kwin-fourier`](https://git.reauktion.de/marfrit/marfrit-packages/src/branch/master/arch/kwin-fourier) — KWin compositor patches addressing scanout-plane / dmabuf-fence behavior on RK3568. Decode-side fix in this campaign + render-side fix in kwin-fourier are complementary; together they make HW video work end-to-end on PineTab2. +- `chromium-fourier` — Chromium fork enabling VAAPI on aarch64 + GL-stack workarounds for Mali-G52/Panfrost. Stock Brave doesn't even reach VAAPI on this rig (GPU process dies at GL bindings); chromium-fourier unblocks it. Verifying compatibility with iter5 driver is iter6 candidate C. + +--- + Single-question campaign on the libva V4L2-stateless backend: **make multi-planar libva work, end-to-end, on Rockchip hantro hardware, for production VA-API consumers (Brave/Chromium, Firefox via libavcodec, mpv `--hwdec=vaapi`, vainfo as smoke test)**. The deliverable is a libva-v4l2-request fork that any VA-API consumer can dlopen and get H.264 (initially) and MPEG-2 hardware-decoded NV12 dmabufs out of, on PineTab2 RK3568 first, with the same plumbing intended to extend to RK3399 (fresnel) and RK3588 (boltzmann/ampere) once the RK3568 path is solid.