From 3144b31ac995371a3103c2419f4219887e54023b Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Sat, 25 Apr 2026 22:51:30 +0000 Subject: [PATCH] ohm browser HW decode: link to chromium-fourier side-project marfrit-packages/arch/chromium-fourier/STUDY.md now holds the plan for patching upstream Chromium to reach VaapiVideoDecoder directly on Linux Wayland, talking to libva-v4l2-request-fourier. README points at it from the existing 'why not Brave's V4L2 / use-system-ffmpeg path' section so a cold-start session sees the next step. 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 cb969f3..62c0783 100644 --- a/README.md +++ b/README.md @@ -297,6 +297,18 @@ multiplanar port. rebuild with different buildflags, or (b) upstream patches to extend the V4L2 decoder factory to Linux non-ChromeOS targets. +#### chromium-fourier (parallel side-project) + +Workspace at `marfrit-packages/arch/chromium-fourier/STUDY.md` — +patching upstream Chromium so it reaches `VaapiVideoDecoder` directly +on Linux Wayland (skipping the chromeos pipeline that fails on Brave), +then talks to our `marfrit/libva-v4l2-request-fourier` libva backend. +No shipping fork covers this niche today (every ARM-Linux Chromium-with- +HW-decode goes through the **vendor MPP path** on **5.10 BSP kernel + +X11 + Mali blob + panfork** — opposite of where Fourier is going). See +that STUDY for the patch shape, reference forks, build plan on fermi +with distcc-avahi acceleration, and validation path. + ### Acceptance criterion **1080p @ 30 fps, no dropped frames.** Applies to every device and every