marfrit-packages/arch/chromium-fourier/NEXT.md

chromium-fourier — first-build status (2026-04-26 00:42 UTC)

Where we are

Build environment: chromium-builder LXD container on boltzmann (8 cores, 28 GB RAM cap, 824 GB NVMe, Beryllium OS rkr3 host kernel). Source: chromium-147.0.7727.116 release tarball extracted at /build/chromium/src (25 GB extracted).

gn gen out/Default succeeds with our 7Ji-style args (use_v4l2_codec=true use_v4lplugin=true use_linux_v4l2_only=true use_vaapi=false, system toolchain via unbundle:default, system clang at /usr/bin/clang, version-symlink /usr/lib/clang/23 → /usr/lib/clang/22, compiler-rt-adjust-paths style suffix patch manually applied). 28057 targets generated.

ninja -C out/Default chrome fails immediately with two distinct walls:

Wall 1 — clang version mismatch (chromium 147 ↔ Arch clang 22)

Chromium 147's compile flags include -fno-lifetime-dse and -fsanitize-ignore-for-ubsan-feature=array-bounds. Both are clang 23+ features. Arch Linux ARM ships clang 22.1.3 (extra repo). Every single C++ compile fails with clang++: error: unknown argument.

Resolutions, in order of effort:

• (a) Wait for Arch ARM to bump clang to 23. Tracking package upstream — happens whenever LLVM 23 lands in extra. Days to weeks.
• (b) Use chromium's bundled clang via tools/clang/scripts/update.py. That hits the same CIPD/gs:// "linux-arm64 isn't a first-class target" issue we saw with gclient sync earlier — chromium's clang prebuilts are x86_64-only for many platforms.
• (c) Fork an older chromium (e.g., 132 or 138) that compiles cleanly with clang 22. 7Ji's chromium-mpp PKGBUILD targets 132 and builds clean on Arch ARM today. Loses 15 versions of upstream chromium evolution but ships fast.
• (d) Patch chromium 147 to drop the offending flags (build/config/compiler/BUILD.gn has the cflags lists). 50–200 line patch, brittle across version bumps but tractable. Fights every rebase.

Wall 2 — bundled x86_64 esbuild under qemu

After Wall 1 (or independently for Action targets): qemu-x86_64-static: Could not open '/lib64/ld-linux-x86-64.so.2' when chromium runs the bundled x86_64 esbuild from third_party/devtools-frontend/.../scripts/build/typescript/ts_library.py. Same shape as the bundled node-linux-x64 issue we already fixed (we symlinked system node into that path). esbuild needs the same treatment — install system esbuild via npm install -g esbuild and symlink it into the path chromium expects. Or install qemu-user-static

• glibc-x86_64 to make the bundled binary actually run.

Wall 2 is much smaller than Wall 1 — a handful of bundled-x86_64 binaries to identify and replace, vs. fundamental clang version mismatch.

What worked

• LXD container provisioning on boltzmann via his recommendation — the host environment is right.
• Tarball-instead-of-gclient approach — sidesteps CIPD-doesn't-have- linux-arm64 problem for source acquisition, leaves only a few bundled binary issues at build time.
• Wall 1 / Wall 2 are both identifiable and bounded. We're past the "is this even doable" phase; this is now down to grinding the patches.

Options — needs your call

1. Grind through Wall 1 with patches — patch build/config/compiler/BUILD.gn to drop flags clang 22 doesn't know. Iterate per build error. Estimated 5–15 patch-and-retry cycles to compile clean. Then 6–10 h actual build.
2. Pin to chromium 132 — match 7Ji's known-working version on Arch ARM. Drop our STUDY focus on "current upstream Chromium" and ship a 1-year-old binary. Build should work much sooner.
3. Pin to chromium 138 or 140 — middle ground. Likely uses clang 22 features and not 23. Some research needed to find the cutover.
4. Use chromium's bundled clang — not viable on linux-arm64 without extensive sysroot setup; same CIPD issue as gclient sync.
5. Wait for Arch ARM clang 23 — passive, days-to-weeks horizon.

Recommended (FWIW): start with (3) — find the latest chromium version that builds clean against clang 22 (probably 138-141 range), ship that as chromium-fourier, then bump as Arch ARM bumps clang. That gives us a working browser in a few hours rather than days, on mainline Linux + Wayland + V4L2 unlock — which is the actual goal. The "current upstream Chromium" requirement was nice-to-have, not essential.

State of the build host (preserved)

• Container: chromium-builder on boltzmann (running, idle)
• Source: /build/chromium/src (extracted tarball, 25 GB)
• Build dir: /build/chromium/src/out/Default (gn-gen'd, no artifacts)
• Tools installed: gn, ninja, clang 22, lld, gperf, nodejs (system), rust, qt5/6, all the gtk/wayland/va/v4l deps from the long pacman shopping list
• Patches applied to source: compiler-rt-adjust-paths style (manual)
• Symlinks: /usr/lib/clang/23 → /usr/lib/clang/22, third_party/node/linux/node-linux-x64/bin/node → /usr/bin/node
• Service unit history: chromium-fetch.service (one-shot, succeeded on tarball + extract); chromium-build.service (one-shot, three failed attempts above).

Discard the container and start over with option 2 if you pick that direction; otherwise iterate from current state.

Pivot 2026-04-26 — cross-compile from x86_64

After the analysis above, the framing shifted. The real wall isn't "Arch ARM clang 22 vs LLVM 23" — Arch x86_64 is also on llvm 22.1.3, no LLVM 23 anywhere in extra/staging. The flags chromium 147 emits (-fno-lifetime-dse, -fsanitize-ignore-for-ubsan-feature=array-bounds, the /usr/lib/clang/23/... path) come from chromium's clang fork, not upstream LLVM 23. Chromium ships its own LLVM with chromium-specific passes; the "23" in the path is chromium-internal versioning.

Implication: PKGBUILD'ing clang 23 is the wrong tree. The right tree is either pin to an older chromium (option 2 above) or cross-compile from an x86_64 host so chromium's x86_64 bundled clang prebuilt is reachable and target_cpu="arm64" produces the aarch64 binary cleanly. Cross-compile sidesteps every wall we hit:

• CIPD has full linux-amd64 prebuilts (the gap was linux-arm64)
• Chromium's bundled clang downloads cleanly on x86_64
• No qemu-x86_64-static dance for tools (host IS x86_64)
• tools/clang/scripts/update.py works as Google intends
• gclient sync works; no DEPS surgery needed

his provisioned a cross-build host for this on 2026-04-26:

• CT 220 chromium-builder-x86 on data, x86_64 Ryzen 7 1700, 14 cores, 32 GiB RAM + 8 GiB swap, 200 GiB ZFS rootfs.
• Reach via mcp__hub-tools__remote_shell host=hertz → ssh root@192.168.88.30 (data) → pct exec 220 -- ...
• builder user uid 1001, NOPASSWD sudo, DisableSandbox in pacman.conf.

Source fetch started 2026-04-26 05:45 UTC as transient unit chromium-fetch.service on CT 220. Estimated 1-2 h for fetch --no-history chromium over the LAN. Then tools/clang/scripts/update.py to install chromium's bundled clang (x86_64 host, arm64 sysroot), then gn gen with target_cpu="arm64" + cross-compile flags, then build.

The boltzmann chromium-builder LXD container is preserved as fallback but no longer the active build host. If cross-compile pans out, that container can be torn down.

First runtime validation on ohm — 2026-04-26 22:26 UTC

Cross-compile produced a working aarch64 binary (chrome 647 MB ELF + chrome_crashpad_handler 4.3 MB + .pak + locales). Tarball chromium-fourier-147.tar.gz (226 MB) transferred CT 220 → hertz → ohm. Launched in mfritsche's KWin Wayland session (tty2, panfrost render node) playing bbb_1080p30_h264.mp4 from file:// with LIBVA_DRIVER_NAME=v4l2_request, LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video0, --use-gl=egl --ozone-platform=wayland --enable-features=VaapiVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxGL --disable-features=UseChromeOSDirectVideoDecoder --autoplay-policy=no-user-gesture-required.

Result: V4L2 path NOT engaged. Chrome 147 routes the H.264 stream through MojoVideoDecoderService → media/filters/ffmpeg_video_decoder.cc (software FFmpeg). Renderer pegs at ~92 % CPU, /dev/video0 is never opened (fuser returns empty), no V4L2VideoDecoder / VaapiVideoDecoder log lines appear at --v=1 --vmodule="*/vaapi/*=2,*/v4l2/*=2,*video_decoder*=2,*media/gpu/*=2". Compositor also fell back to software (Switching to software compositing. even though panfrost render node was picked) — secondary issue, separate from the codec wall.

Conclusion: 7Ji-style gn args (use_v4l2_codec=true use_v4lplugin=true use_linux_v4l2_only=true) alone are insufficient on chromium 147. The V4L2VideoDecoder factory is still gated behind BUILDFLAG(IS_CHROMEOS) — media/mojo/services/gpu_mojo_media_client_*.cc and media/gpu/gpu_video_decode_accelerator_factory.cc only register the V4L2 path on ChromeOS targets.

Validation pass 2 — 2026-04-26 22:38 UTC — V4L2VDA proven engaged

Two distinct issues were diagnosed and the codec one was fully resolved without source surgery beyond a 2-line patch:

Issue 1 — runtime master gate

media::kAcceleratedVideoDecodeLinux (user-visible feature name "AcceleratedVideoDecoder") is hard-coded in media/base/media_switches.cc:750 to FEATURE_ENABLED_BY_DEFAULT only when BUILDFLAG(USE_VAAPI) is set. On a USE_V4L2_CODEC-only build it defaults DISABLED, the linux gpu_mojo_media_client returns VideoDecoderType::kUnknown, and chrome silently falls back to media/filters/ffmpeg_video_decoder.cc.

Fix: 2-line patch (now patches/enable-v4l2-decoder-default.patch):

-#if BUILDFLAG(USE_VAAPI)
+#if BUILDFLAG(USE_VAAPI) || BUILDFLAG(USE_V4L2_CODEC)

The placeholder chromeos-pipeline-bypass.patch was deleted; PKGBUILD now references the real patch. Verified to apply cleanly on the CT 220 tree (chromium 149 main).

Issue 2 — bundled GL libs missing from tarball

The first runtime tarball shipped only chrome + .pak + locales + chrome_crashpad_handler. It omitted libEGL.so / libGLESv2.so (ANGLE) plus libvk_swiftshader.so and libvulkan.so.1. Without these, the GPU process logs gl::init::InitializeStaticGLBindingsOneOff failed and chrome falls into "Switching to software compositing." mode — which also gates the V4L2 path off because the gpu_mojo_media_client never gets a chance to dispatch.

Additionally, --use-gl=egl is rejected ("Requested GL implementation gl=egl-gles2,angle=none not found in allowed implementations: [(gl=egl-angle,angle=opengl|opengles|vulkan)]"): the build only allows ANGLE-mediated paths. Right launcher invocation: --use-gl=angle --use-angle=gles.

Fix: package the four libs alongside chrome and update the launcher flag set. Both will be encoded in the next iteration of the PKGBUILD's package() and a chromium-fourier launcher script.

What we observed once both fixes were in place

With patch + bundled libs + --enable-features=AcceleratedVideoDecoder

• --use-gl=angle --use-angle=gles, chrome on RK3566 hantro logs:

[gpu]: V4L2VideoDecoder()
[gpu]: Open(): No devices supporting H264 for type: 0     <- type=0 is single-planar; chrome retries multi-planar
[gpu]: InitializeBackend(): Using a stateless API for profile: h264 main and fourcc: S264
[gpu]: SetupInputFormat(): Input (OUTPUT queue) Fourcc: S264
[gpu]: AllocateInputBuffers(): Requesting: 17 OUTPUT buffers of type V4L2_MEMORY_MMAP
[gpu]: SetExtCtrlsInit(): Setting EXT_CTRLS for H264
[gpu]: SetupOutputFormat(): Output (CAPTURE queue) candidate: NV12
[gpu]: ContinueChangeResolution(): Requesting: 6 CAPTURE buffers of type V4L2_MEMORY_MMAP
[renderer]: OnDecoderSelected<video>: V4L2VideoDecoder
MediaEvent: "Selected V4L2VideoDecoder for video decoding,
             config: codec: h264, profile: h264 main, [...]
             coded size: [1920,1080], visible rect: [0,0,1920,1080]"

fuser /dev/video1 /dev/media0 shows chrome (gpu pid) holding both fds. The hantro stateless decoder is engaged. First end-to-end chromium-fourier V4L2 hardware decode validation: PASS for H.264 1080p Big Buck Bunny on PineTab2.

Caveat: the render-side CPU was still ~85% during playback. Subsequent investigation traced this to a different root cause than initially guessed (see Pass 3 below).

Validation pass 3 — 2026-04-26 22:50 UTC — zero-copy diagnosis

The 85 % CPU is not caused by software compositing or dmabuf v5 negotiation. The dmabuf-v5 warning ("Binding to zwp_linux_dmabuf_v1 version 4 but version 5 is available") is benign — chrome happily binds to its supported max (v4). The WaylandZwpLinuxDmabuf::OnTrancheFlags NOTIMPLEMENTED is also benign — KWin sends it, chrome ignores it, but the substantive feedback (formats + modifiers) lands via OnTrancheFormats / OnTrancheTargetDevice regardless.

Real cause: gpu_feature_info.supports_nv12_gl_native_pixmap ends up false on this build. With it false, V4L2-decoded NV12 frames go through the NV12-to-AR24 VPP conversion path (see media/mojo/services/gpu_mojo_media_client_linux.cc GetPreferredRenderableFourccs — without NV12 native pixmap support, only Fourcc::AR24 is added to the renderable set, forcing the VPP). That's where the 85 % is spent.

Why is supports_nv12_gl_native_pixmap false? GLOzoneEGLWayland::CanImportNativePixmap (in ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc) requires the chrome GL display to expose EGL_EXT_image_dma_buf_import. With --use-gl=angle --use-angle=gles, chrome's GL display sits behind ANGLE's EGL, and ANGLE's GLES backend on Linux does not propagate EGL_EXT_image_dma_buf_import from the underlying mesa EGL up to its clients. Verified directly: EGL_PLATFORM=surfaceless eglinfo on ohm shows panfrost native EGL exposes both EGL_EXT_image_dma_buf_import and EGL_EXT_image_dma_buf_import_modifiers — the capability is there at the panfrost layer, ANGLE just hides it.

We tried --use-gl=egl (direct EGL/GLES2, bypass ANGLE) but were rejected with "Requested GL implementation (gl=egl-gles2,angle=none) not found in allowed implementations". WaylandSurfaceFactory::GetAllowedGLImplementations() in chromium 149 advertises only ANGLE-mediated impls; the kGLImplementationEGLGLES2 slot is missing from the list. The CreateViewGLSurface dispatcher does still handle that impl — only the advertisement was tightened.

Patch 2/2 — wayland-allow-direct-egl-gles2.patch

3-line diff in ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:

+    impls.emplace_back(gl::GLImplementationParts(gl::kGLImplementationEGLGLES2));
     impls.emplace_back(gl::ANGLEImplementation::kOpenGL);

Re-allows the direct EGL/GLES2 path, ahead of the ANGLE entries so chrome picks it by default. Verified to apply cleanly on the CT 220 tree; staged via patch -p1 mid-rebuild (ninja's mtime-based rebuild will pick up the change automatically).

Outstanding for next pass (revised)

1. Rebuild lands → repackage with all four GL libs + chrome_crashpad_handler + chrome → ship to ohm.
2. Validate via chrome --use-gl=egl --ozone-platform=wayland --enable-features=AcceleratedVideoDecoder (no ANGLE shim) and confirm chrome://gpu reports Native GpuMemoryBuffers: true and supports_nv12_gl_native_pixmap=true. Target CPU during 1080p30 H.264 playback: under 30 % combined renderer + gpu.
3. If (2) passes, declare V1 of chromium-fourier shippable on ohm.
4. Add a chromium-fourier launcher shim under /usr/bin/ that defaults to --use-gl=egl --ozone-platform=wayland.
5. Sort the chromium 147 vs 149 confusion — the fetch went to ToT on main rather than the 147 release branch. Either pin the branch or accept that we're tracking ToT (probably preferable for V4L2 fixes that are still in flight upstream).
6. Replicate end-to-end on RK3588 (ampere CoolPi or boltzmann Rock 5 ITX+) once the mainline VDPU381 driver is stable on those — those boxes use panthor for Mali-G610 (Valhall), not panfrost; the patches should be backend-agnostic but the validation is per-box.

State of the build host (post pass 3)

• CT 220 /build/chromium/src patched with both enable-v4l2-decoder-default.patch and wayland-allow-direct-egl-gles2.patch (applied directly with patch -p1 mid-rebuild; ninja picks up the mtime change).
• chromium-rebuild.service running as a transient unit, output in /tmp/chromium-rebuild.log. Most of the 93k ninja steps are cache hits; only the patched files + their downstream objects need recompiling.
• Tarball still on CT 220 at /build/chromium-fourier-147.tar.gz (misleadingly named: it's actually 149.0.7812.0 from the main fetch, not the 147 release tarball — separate cleanup for next pass) and on hertz at /tmp/chromium-fourier-147.tar.gz. Will be replaced by the post-rebuild tarball once it lands.

---

2026-04-28 — Patch 4 lands, KWin owns the residual stall

Patch 4 — nv12-external-oes-on-modifier-external-only.patch

On panfrost / panthor, every NV12 modifier (LINEAR + AFBC ×2 + AFRC) is flagged external_only in eglQueryDmaBufModifiersEXT. Chromium's OzoneImageGLTexturesHolder::GetBinding only picked GL_TEXTURE_EXTERNAL_OES when the SharedImageFormat carried PrefersExternalSampler — which is set for the generic Linux multi-plane case but not for V4L2 producers that arrive via the standard ozone pixmap path. The frame then took the GL_TEXTURE_2D branch, ANGLE's validationES.cpp:4894 rejected the YUV EGLImage on a non-EXTERNAL_OES target, the import failed, and the renderer fell back to the NV12→AR24 software conversion (~131 % CPU baseline).

Patch closes the gap: also pick EXTERNAL_OES when the EGL driver advertises the pixmap's modifier as external_only (cached per (fourcc, modifier) tuple via a function-local base::flat_map+base::Lock, so the EGL round-trip stays off the per-frame hot path). Adds a single static helper NativePixmapEGLBinding::ModifierRequiresExternalOES. ~+90 lines, zero deletions, no shader changes (Skia Ganesh already handles GL_TEXTURE_EXTERNAL_OES natively via GrGLTextureInfo.fTarget).

Validation on ohm (RK3566 PineTab2 / hantro mainline 6.19.10)

• bbb_1080p30_h264.mp4 plays clean, no garble, no decoder error
• Steady-state 34.7 % combined CPU during 1080p30 H.264 (browser 12 + GPU 9 + net 6 + render 6 + audio 1) vs v3 baseline ~131 % — ~3.8× reduction. Risk-1 (ANGLE+EXTERNAL_OES sampling regression on Skia Ganesh / panfrost) cleared.
• V4L2VideoDecoder() constructor + Using a stateless API for profile: h264 main and fourcc: S264 confirmed in log; 6 CAPTURE buffers V4L2_MEMORY_MMAP, NV12 output. 19 live dmabuf fds in GPU process during steady playback — healthy V4L2 rotation + compositor depth, not a leak.

KWin 6.6.4 GL_ALPHA bug — separate, preexisting, blocks long playback

Across BOTH v3 (no patch 4) and v4 (with patch 4) chromium-fourier builds, mid-playback the renderer + GPU process both park in futex_do_wait, <video> element keeps its ⏸ icon, currentTime advances on the audio clock, and audio outputs static (last ALSA buffer recycled) then silence. No D-state, no v4l2/vb2/dma_fence wchan, no error in chrome-v[34].log.

journalctl for kwin_wayland:

GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_ALPHA)
GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0) × N

First occurrence on this box: 2026-03-06. KWin is requesting an internal format that doesn't exist in modern GLES (GL_ALPHA is GLES1.x legacy, not valid for glTexImage2D with GLES3 contexts). The allocation fails, then every glTexSubImage2D to that texture errors at level 0; KWin keeps retrying the same broken upload every frame, never recovers. The frame-callback ack to wayland clients stalls → chrome's renderer parks waiting for the present-feedback that never lands.

Patch 4 looks "guilty" only because of timing: with NV12 zero-copy, the renderer is fast enough to actually post a v4l2-backed dmabuf within the window where KWin's broken path runs; v3 was slow enough (NV12→AR24 software conversion) that the bug surfaced 5–10× later. Triangulation: chrome v4 stalls + chrome v3 stalls + VLC cannot convert decoder/filter output + mpv could not initialize video chain — every wayland video client hits it; ffmpeg -hwaccel v4l2request -f null plays through clean (decode path is healthy, the wall is the compositor's GL backend).

Decoder-stack sanity post-reboot (2026-04-28 ~13:30)

After a reboot the V4L2 device numbering shuffled:

• /dev/video0 = rockchip,rk3568-vpu-dec (hantro DEC, was video1)
• /dev/video1 = rockchip,rk3568-vepu-enc (hantro ENC)
• /dev/video2 = rockchip-rga
• /dev/media0 = controller for DEC, /dev/media1 = controller for ENC

Anything that hardcoded /dev/video1 for decode now talks to the encoder. Chrome and ffmpeg both handle this transparently (they enumerate via media-ctl); mpv's --hwdec=v4l2request returns Could not create device post-shuffle — separate mpv-side bug, not ours.

Outstanding (revised, supersedes earlier list)

1. Patch 4 lands publicly: bump PKGBUILD source= and prepare(), commit + tag a chromium-fourier-149-r4 release on git@github.com:marfrit/chromium-fourier.
2. KWin pivot — see KWIN_PIVOT.md (separate doc) for the plan to identify and patch the glTexImage2D(GL_ALPHA) site, since ohm is the only board on hand and every wayland video client is affected.
3. Replication on ampere (RK3588, panthor + rkvdec2 + hantro multiplanar) — needs ampere woken; currently DOWN.
4. firefox-fourier 150 build — firefox-fourier-150.0.1-1-aarch64.pkg.tar.zst is built (95 MB on workstation:/tmp/, sha256 acbf1870…), pending fresnel power-on for V4L2 stateless validation on RK3399.