9 Commits

Author	SHA1	Message	Date
marfrit	58f67d4b2c	chromium-fourier: bump to 148.0.7778.178, add Debian recipe ... Arch: version 147→148, drop enable_nacl (removed upstream), fix nv12-external-oes patch context for 148 (base/numerics/safe_conversions.h include removed upstream). Header comment updated: native build fiction → cross-compile reality. Debian: new build-deb.sh that assembles .deb from pre-built artifacts on CT 220 (data). Same binary artifacts as the Arch package, launcher at /usr/bin/chromium-fourier (no Conflicts with stock chromium on Debian). Both packages published to packages.reauktion.de: - Arch: marfrit/aarch64/chromium-fourier 1:148.0.7778.178-1 - Debian: trixie+bookworm/main/arm64 chromium-fourier 1:148.0.7778.178-1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-05-24 09:45:30 +02:00
marfrit	13a7566c34	KWIN_PIVOT: campaign closed end-to-end (part 3 update) ... 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.	2026-04-28 18:51:37 +00:00
marfrit	93d7c5c67a	KWIN_PIVOT: Phase-4 done (qt6 patches landed) + weston A/B vindicates KWin theory ... 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.	2026-04-28 15:35:01 +00:00
marfrit	cd25d02e01	KWIN_PIVOT: Phase-2 findings — bug is in Qt 6, not KWin ... 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.	2026-04-28 12:18:25 +00:00
marfrit	8756ce38be	chromium-fourier r2 + firefox-fourier 150.0.1 + KWIN_PIVOT.md ... chromium-fourier: - patch 3/3 nv12-external-oes-on-modifier-external-only.patch — adds NativePixmapEGLBinding::ModifierRequiresExternalOES helper, extends OzoneImageGLTexturesHolder::GetBinding to honor EGL external_only flag for NV12 dmabufs on panfrost / panthor. Validated on ohm (RK3566 hantro mainline 6.19.10): bbb_1080p30_h264.mp4 plays at 34.7 % combined CPU vs ~131 % pre-patch baseline (~3.8x). - PKGBUILD pkgrel 1->2, source array + sha256sums + prepare() hook for patch 4, patch numbering 1/2,2/2 -> 1/3,2/3,3/3. - NEXT.md appended with 2026-04-28 section: patch 4 design, validation log, KWin GL_ALPHA bug pinpoint (preexisting since 2026-03-06, affects every wayland video client; unrelated to chromium-fourier), device-renumbering note (/dev/video1 = encoder post-reboot). - KWIN_PIVOT.md: 4-phase plan to identify and patch KWin's glTexImage2D(internalFormat=GL_ALPHA) site, ohm-only test plan, scope discipline. - patches/ now tracked (compiler-rt-adjust-paths, enable-v4l2, wayland-allow-direct-egl-gles2, nv12-external-oes); the dead-end chromeos-pipeline-bypass.patch removed. firefox-fourier: - 4 patches (gfxinfo v4l2 stateless fourccs, libwrapper hwdevice ctx, ffmpegvideo v4l2-request route, prefs v4l2-request default). - PKGBUILD bumped to firefox 150.0.1, Arch toolchain glue patches layered in, mozconfig with --without-wasm-sandboxed-libraries for ALARM, package() launcher fix (rm -f symlink before cat > to avoid ENOENT through the dangling /usr/local symlink mach install drops). - 150.0.1-1-aarch64.pkg.tar.zst built on boltzmann (95 MB), pending fresnel power-on for V4L2 stateless validation on RK3399.	2026-04-28 12:02:18 +00:00
test0r	7bb2fbeca9	chromium-fourier: pivot to x86_64 cross-compile from CT220 on data ... 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>	2026-04-26 05:57:14 +00:00
test0r	f3a7b8f1c1	chromium-fourier NEXT.md: hit the clang 22 vs 147 wall ... 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>	2026-04-26 01:02:24 +00:00
test0r	055fc0ba06	arch/chromium-fourier: scaffold PKGBUILD + placeholder patch ... 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>	2026-04-25 23:28:12 +00:00
test0r	f4bdd54543	arch/chromium-fourier: workspace + STUDY.md (no PKGBUILD yet) ... 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>	2026-04-25 22:51:01 +00:00