Three patches landed on ohm in sequence today: qt6-base-fourier
(GL_ALPHA → GL_R8 on ES 3.x, 3 sites in qtbase), kwin-fourier
(watchDmaBuf no-op test fixture), chromium-fourier patch 4/4
(V4L2 capture pool floor at 16). Each unsticks one layer.
Together they produce smooth 1080p30 H.264 playback under KDE
Plasma 6.6.4 Wayland on RK3566 PineTab2 mainline, where stock
chromium previously stalled in 3 seconds. Combined chrome CPU
~81% steady, KWin ~9%, zero GL_INVALID_VALUE during playback.
Brave's YouTube on the same compositor session also feels snappier
independently — the kwin-fourier watchDmaBuf bypass is a
general-purpose latency reduction for every wp_linux_dmabuf client
on Mali-class hardware, not chrome-specific.
The kernel-side architectural hole is the right upstream-correct
fix: vb2 / hantro / rga don't populate dma_resv exclusive fences
for V4L2 producers, so dma_buf_export_sync_file substitutes a stub
fence representing nothing real. Per-driver fence wiring (3 small
commits: vb2 helper API, hantro opt-in, rga opt-in) plus a parallel
KWin commit using poll(POLLIN) directly on the dmabuf fd is the
planned MR pair. kwin-fourier as it stands is a working diagnostic,
not the upstream-bound shape.
Today's deltas:
- qt6-base-fourier built, installed, validated on ohm. Static-idle
journal shows zero GL_INVALID_VALUE post-relogin; the Qt 6
GL_ALPHA bug is genuinely fixed.
- chrome v4 under KWin still stalls — at ~6s vs ~3s pre-Qt-fix, so
the GL_ALPHA churn was contributing some load but wasn't the
primary cause.
- Clean A/B with weston: same chrome v4 binary, same panfrost,
same V4L2, same hardware → swapping KWin → weston turns the
stall off entirely. Chrome plays through with elevated CPU
(~96 % vs KWin's ~50 % when it isn't stalled) because weston
falls back to LINEAR composite vs KWin's fast-tile path.
- mpv triangulation:
--vo=null --hwdec=v4l2request: clean (decode only)
--vo=drm --hwdec=v4l2request: 0.7 % drops in 19 s (KMS scanout)
--vo=gpu-next --hwdec=v4l2request under KWin: 76 % drops, slideshow
Decode + display hardware path is fully capable. The wall is
specifically KWin's compositor scheduling/presentation pipeline on
this stack — panfrost ES 3.2 + V4L2 stateless NV12 dmabuf clients.
KWIN_PIVOT.md rewritten:
- Phase 4 (qt6 patch, ship, upstream) marked done.
- New Phase 5 (find the KWin culprit): WAYLAND_DEBUG on chrome +
KWin to capture the missing wl_buffer.release / wp_presentation
exchange around the 6 s stall, plus strace-on-kwin and
effects-disable bisection.
- New Phase 6 (fix and ship): kwin-fourier package pattern, ohm
validation, bugs.kde.org filing.
Source-grep collapsed Phase 1+2 onto a single pass. KWin's own GL paths
use GL_R8 correctly (gltexture.cpp:61, shadowitem.cpp:494). The
glTexImage2D(GL_ALPHA) calls observed in the journal originate from
Qt 6:
- qtbase/src/opengl/qopengltextureglyphcache.cpp:111-117 — text glyph
cache upload path. The #else branch (active when qtbase is built
with QT_CONFIG(opengles2)) unconditionally uses GL_ALPHA, with no
runtime check for ES context major version. Correct on ES 2.x;
broken on ES 3.x where GL_ALPHA is no longer a valid glTexImage2D
internalFormat.
- qtbase/src/gui/rhi/qrhigles2.cpp:1373-1378 — Qt-Quick-RHI sibling.
Same logic, gated only on caps.coreProfile, missing the ES≥3 case.
- qtbase/src/opengl/qopengltextureuploader.cpp:253-257 — QImage→GL
upload path; same shape.
KWin runs an ES 3.2 context on Mali-G52 panfrost (RK3566), Qt picks
GL_ALPHA, mesa returns GL_INVALID_VALUE, every dependent draw errors
at level 0, the compositor's frame-callback path stalls. KWin is the
visible victim because it's the compositor, but the bug is in Qt.
KWIN_PIVOT.md rewritten: the patch series and packaging now target
qt6-base-fourier instead of kwin-fourier. Three small hunks (~3 lines
each), runtime-safe via existing caps.gles + caps.ctxMajor / surface
format majorVersion checks. Upstream landing path: bugreports.qt.io
+ Gerrit change against qtbase dev branch.
Earlier framing was wrong — the wall isn't 'Arch ARM clang 22 vs Arch
x86_64 clang 23'. Arch x86_64 is also on 22.1.3; LLVM 23 isn't anywhere
in extra/staging. The flags chromium 147 emits come from chromium's
clang fork (Google maintains an LLVM fork with chromium-specific
passes), not upstream LLVM 23. PKGBUILD'ing clang 23 is the wrong tree.
Right tree: cross-compile from x86_64 so chromium's bundled clang
prebuilt is reachable. CIPD has full linux-amd64 prebuilts, gclient
sync works cleanly, no qemu-x86_64-static dance needed.
his provisioned CT 220 chromium-builder-x86 on data (Ryzen 7 1700,
14 cores, 32 GiB RAM, 200 GiB ZFS). data is normally asleep — woke
via /opt/herding/bin/wake-data. Reach pattern: hertz -> ssh data ->
pct exec 220.
Source fetch running as chromium-fetch.service transient unit on
CT 220. Once src is in, plan: tools/clang/scripts/update.py for
chromium's bundled clang + arm64 sysroot, gn gen with target_cpu=arm64,
build, transfer aarch64 binary to ohm/fresnel/ampere.
boltzmann chromium-builder LXD container preserved as fallback; can
be torn down if cross-compile pans out.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First-build summary on chromium-builder@boltzmann. gn gen succeeds
with our V4L2VDA-unlock args. ninja fails immediately on:
1. chromium 147 emits clang flags (-fno-lifetime-dse,
-fsanitize-ignore-for-ubsan-feature=array-bounds) that clang 22
doesn't know. Arch Linux ARM is on clang 22; clang 23 hasn't
landed in extra yet.
2. Bundled x86_64 esbuild is invoked via qemu-x86_64-static but
/lib64/ld-linux-x86-64.so.2 isn't installed — same shape as the
bundled node-linux-x64 issue we already fixed by symlinking to
system node. Smaller wall.
Documents 5 paths forward (grind patches / pin chromium 132 (7Ji's
known-good) / pin 138-141 middle ground / use chromium's bundled
clang / wait for Arch ARM clang 23) with estimated effort and trade-
offs. Recommends pinning to a chromium version that compiles clean
against clang 22 as the fastest path to a working browser, then
bumping as Arch ARM bumps clang.
Build host state preserved — container running, source extracted,
gn-gen'd, no compile artifacts. Easy to resume from any of the five
paths.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Initial chromium-fourier shape on the chromium-builder@boltzmann LXD
container we provisioned today. Approach is the 7Ji-style "tarball +
system tools" pattern (no gclient/CIPD, the linux-arm64 dependency
binaries don't exist anyway) but stripped of the MPP/X11/panfork
specifics — chromium-fourier targets mainline kernel + Wayland +
panfrost/panthor + V4L2 stateless on /dev/video0, not the vendor
stack 7Ji's chromium-mpp targets.
PKGBUILD highlights:
- pkgver=147.0.7727.116 (current Chrome stable as of 2026-04-25)
- gn args: use_v4l2_codec=true, use_v4lplugin=true, use_linux_v4l2_only=true,
use_vaapi=true. The first three are the magic that unlocks V4L2VDA on
Linux non-ChromeOS without source patches; if they're sufficient on
their own, the chromeos-pipeline-bypass patch stays a no-op.
- ffmpeg_branding="Chrome" + proprietary_codecs=true for H.264.
- enable_widevine=false, enable_nacl=false to keep the tree small.
- Currently development-shaped: prepare()/build() operate on a
pre-extracted /build/chromium/src rather than makepkg-fetched
source. Will switch to canonical source=(...tarball.xz) shape once
the patches stabilise.
patches/chromeos-pipeline-bypass.patch is a placeholder; the actual
patch (if any) gets developed once we see what 7Ji's gn args do or
don't unlock for us.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stage the next side-project: patch upstream Chromium to do HW video
decode through VaapiVideoDecoder + our marfrit/libva-v4l2-request-fourier
backend on a mainline Linux Wayland system, instead of going through
the chromeos pipeline that fails on Brave today.
STUDY.md captures:
- The exact failure stack we're fixing (PickDecoderOutputFormat ->
ImageProcessor init failure in media/gpu/chromeos/video_decoder_pipeline.cc)
- Three candidate patches (chromeos pipeline bypass, V4L2VideoDecoder
factory un-gate, libva backend default)
- Reference forks (JeffyCN, igel-oss, 7Ji-PKGBUILDs/chromium-mpp,
amazingfate/chromium-debian-build) — all use the older V4L2VDA path
with vendor MPP, not VAAPI; useful for PKGBUILD shape and
factory-un-gating patterns but not directly applicable
- Build plan on fermi (depot_tools, ~30 GB fetch, 6-10 h initial build,
distcc-avahi acceleration through CT108 + tesla)
- Phase order — workspace done now, build env next session,
patches after that, package after that, brave-fourier rebase last
No PKGBUILD added yet; one will land when there's something to actually
package. Build artifacts intentionally not in repo (chromium tree is
~100 GB).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit
test0r