106 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
claude-noether	f41e9a117b	firefox-fourier: fix patches layout — ship arch-*.patch + reference patches/ ... The PKGBUILD has been structurally broken since at least the 150.0.1 import: source array referenced patches at top level ('0001-...patch') but the actual files live in patches/ — makepkg searched for them in the package root and failed before doing any work. The arch-0002/3/4 upstream toolchain patches (clang 22, glibc 2.43, Rust 1.95) weren't shipped in the repo at all. Caught when boltzmann tried to build 150.0.1-2 (PR #9 follow-up); fails at the source-staging phase with: ==> ERROR: arch-0002-Bug-2033279-Make-enable-rust-simd-work-with-Rust-1.9.patch was not found in the build directory and is not a URL. Why nobody noticed: firefox-fourier has no Gitea Actions job (too heavy for the runner pool). The shipped 150.0.1-1 .pkg.tar.zst was produced by hand-staging files; the PKGBUILD itself never reproduced from a clean checkout. This commit: - Moves all source-array patch references under patches/ to match the on-disk layout (same convention as chromium-fourier). - Updates prepare() paths accordingly. - Adds arch-0002/3/4 patches fetched verbatim from https://gitlab.archlinux.org/archlinux/packaging/packages/firefox (raw/main/{0002,0003,0004}-...patch). Renamed with arch- prefix in the repo to avoid namespace collision with the local 0001..0005. - Adds the previously-omitted 0005-rdd-sandbox-v4l2-media-ctl.patch to the source array + prepare(); this is the patch that broadens the RDD sandbox so /dev/media* and /dev/video* ioctls reach the decoder child (README §1 enumerates it as load-bearing for the HW path). It was present in patches/ but not wired up. Dry-run verified all 8 patches apply cleanly against firefox-150.0.1 source (some hunks offset by ≤3 lines, no conflicts). pkgrel 2 -> 3.	2026-05-15 07:24:30 +00:00
marfrit	2f78136479	Merge pull request 'fresnel-fourier stack: bump libva to iter38b + fix firefox HW-decode defaults (#8)' (#9) from claude-noether/marfrit-packages:noether/libva-iter38b-and-firefox-prefs into main ... Reviewed-on: #9	2026-05-15 06:13:19 +00:00
claude-noether	62a594ab59	firefox-fourier: ship RK3399 HW-decode default prefs (closes #8) ... Three prefs that gate the patched VAAPI / V4L2-request code path are 'false' upstream and need to be 'true' for the libva-v4l2-request backend to actually engage on RK3399 / panfrost EGL: widget.dmabuf.force-enabled media.hardware-video-decoding.force-enabled media.ffvpx-hw.enabled Without them, Gecko's DMA-BUF probe silently fails (panfrost EGL doesn't trip the right detection), the (Intel-tuned) HW-vs-SW cost heuristic picks SW, and the FFvpx PDM never selects its HW-capable variant for VP8/VP9. Net result: fresh profiles SW-decode despite the 0001..0004 unlock patches being applied. Shipped as a vendor-default file at: /usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js Lower precedence than user.js / about:config — power users debugging HW decode can still flip them off without touching the package. pkgrel 1 -> 2. Closes: #8	2026-05-15 06:10:01 +00:00
claude-noether	81cc050bf3	libva-v4l2-request-fourier: bump pin iter8 -> iter38b (7ac934e) ... Carries the fork from libva-multiplanar iter8 close (2026-05-06) to fresnel-fourier iter38b (2026-05-14): multi-device probe so a single libva session serves rkvdec (H.264 + HEVC + VP9) + hantro (MPEG-2 + VP8) without LIBVA_V4L2_REQUEST_VIDEO_PATH overrides, plus the MAX_PROFILES bounds-check fix from iter38b. Required by the fresnel-fourier README's HW-decode stack (vainfo exposes all 10 profiles in one session, byte-exact bench verified across 5 codecs). 68 commits between the old pin (65969da3) and the new (7ac934e0). pkgver() recomputes the rev count at build time; the static placeholder is bumped from r280 to r348 to reflect the new pin.	2026-05-15 06:08:21 +00:00
Claude (noether)	ee636a6d21	mpv-fourier: iter2 — wire v4l2request hwdec through drmprime VO ... Adds Kwiboo / Langdale's 2024-08 patches (0001-meson + 0002-vo-hwdec-drmprime) so AV_HWDEVICE_TYPE_V4L2REQUEST flows through mpv's drmprime VO hwdec and `--hwdec=v4l2request` engages against the dmabuf-wayland VO instead of failing with "Could not create device". The matcher previously filtered on AV_HWDEVICE_TYPE_DRM and rejected v4l2request even when libavcodec's hwaccel returned a valid PRIME descriptor. PKGBUILD: pkgrel 9 → 10, source[] picks up both new patches, prepare() applies them before the existing 0001-vo_dmabuf_wayland cache-sync workaround, meson build flag -Dv4l2request=enabled added so the new option compiles in. Stacks on top of iter1 (713a856): the dma_buf cache-sync workaround stays load-bearing for the existing vaapi_dmabuf and drmprime_dmabuf import paths; this iter only adds the wiring for the drmprime VO's hwdec selector. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-15 05:52:22 +00:00
marfrit	948088fc28	distcc-avahi: pkgrel=20 — skip stale 19 slot, ship masquerade symlinks (closes #7)	2026-05-09 19:22:18 +00:00
marfrit	7fbe289767	linux-fresnel-fourier: fix headers pkg — install -d usr/src before symlink	2026-05-09 17:45:56 +00:00
marfrit	83ecae29bf	linux-fresnel-fourier: drop distcc from build() — native only per kernel-agent policy	2026-05-09 17:00:29 +00:00
marfrit	f3dac89c49	linux-fresnel-fourier: snapshot of fresnel running .config (linux-eos-arm 6.19.10-1)	2026-05-09 15:27:12 +00:00
marfrit	2ca7f0c822	linux-fresnel-fourier: bootstrap 0003-arm64-dts-rk3399-pinebook-pro-spi1-max-freq-10MHz.patch	2026-05-09 15:27:11 +00:00
marfrit	ab0091009b	linux-fresnel-fourier: bootstrap 0002-arm64-dts-rk3399-pinebook-pro-enable-hdmi-sound.patch	2026-05-09 15:27:10 +00:00
marfrit	371d1f8ee3	linux-fresnel-fourier: bootstrap 0001-arm64-dts-rk3399-pinebook-pro-add-OC-OPP-tables-1704-2184.patch	2026-05-09 15:27:10 +00:00
marfrit	445937a4af	linux-fresnel-fourier: bootstrap extlinux-add.sh	2026-05-09 15:27:09 +00:00
marfrit	9834fcd71d	linux-fresnel-fourier: bootstrap extlinux-add.hook	2026-05-09 15:27:08 +00:00
marfrit	3ea8327ad1	linux-fresnel-fourier: bootstrap linux-fresnel-fourier.preset	2026-05-09 15:27:07 +00:00
marfrit	b5db9ad07c	linux-fresnel-fourier: bootstrap PKGBUILD	2026-05-09 15:27:06 +00:00
test0r	713a856cdc	mpv-fourier: iter1 patch — explicit DMA_BUF_IOCTL_SYNC on import fds ... Workaround for the dmabuf-wayland green-frames bug (marfrit/dmabuf-modifier-triage#1). iter1 phase 2 source-read of KWin 6.6.4 + Mesa 26.0.6 ruled out the original H1/H2 hypotheses (panfrost offset handling and KWin wl_dmabuf import are clean) and matched the green tone to BT.601 limited-range YUV(0,0,0) -> RGB(0, 135, 0). Conclusion: panfrost reads zero-fill memory despite hantro having written real data — a cache-coherency / synchronization gap. V4L2 doesn't attach implicit fences (dma_resv) to CAPTURE buffers on VIDIOC_DQBUF; this gap is the same one our vb2_dma_resv RFC v2 addresses upstream. The userspace workaround is to issue DMA_BUF_IOCTL_SYNC(SYNC_START|SYNC_RW) + SYNC_END(SYNC_RW) on each EXPBUF fd before submitting to the compositor — invokes the producer driver's begin_cpu_access / end_cpu_access path, which on most ARM SoCs flushes write buffers and synchronizes coherent memory. Patch covers BOTH vaapi_dmabuf_importer (the path our test exercises via `mpv --hwdec=vaapi`) and drmprime_dmabuf_importer (for symmetry when used via `--hwdec=drmprime`). If this works, ship it; if it doesn't, hypothesis space narrows further to GPU-side cache invalidation in panfrost's kernel-mode dma_buf import path (H7). pkgrel 8 -> 9. Patch sha256 6c929bea7636b8d81b63a1275ba1d8a471fe2f249fc23509043ace6cf9b076a7.	2026-05-08 22:03:26 +00:00
Claude (noether)	6738fabea0	ci: kill stale gpg-agent before wiping /root/.gnupg ... `rm -rf /root/.gnupg` removes the homedir and its socket file but does not kill the gpg-agent process that was watching the original inode. The next gpg invocation on the fresh homedir then races a half-dead agent: `gpg --import-ownertrust` reports "can't connect to the gpg-agent: IPC connect call failed" and the import-key step exits non-zero under set -e, killing the job. Run 78 lmcp-any landed on this. The previous run's ffmpeg job spawned an agent at /root/.gnupg/S.gpg-agent and was still alive when lmcp-any prep ran. Add `gpgconf --homedir /root/.gnupg --kill all` immediately before each of the six `rm -rf /root/.gnupg /root/repo_pass` sites. `|| true` keeps the first-ever run's missing-agent case quiet.	2026-05-08 21:30:59 +00:00
Claude (noether)	c2e40dbf9a	ci: bump MAKEFLAGS to -j60 for ffmpeg/libva/mpv builds ... distcc-avahi 3.4-19 + the ffmpeg --cc=distcc-shim landing means fermi can actually fan compiles out across the zeroconf pool. With MAKEFLAGS="-j$(nproc)" the runner only had ~3 outstanding TUs at a time, leaving ~57 worker slots idle. Bump to -j60 to fill the pool (tesla 16 + dcc1 16 + dcc2 16 + boltzmann 10 + a few local).	2026-05-08 21:06:00 +00:00
Claude (noether)	d6ba22983a	ffmpeg-v4l2-request: pkgrel=4 — use distcc shim when BUILDENV=distcc ... FFmpeg's configure script resolves the compiler via `which gcc` and bakes the absolute path /usr/bin/gcc into the generated makefiles. With BUILDENV=(distcc ...) makepkg prepends /usr/lib/distcc/bin to PATH, but configure has already resolved past the shim — so every translation unit compiles locally despite the worker pool being available. Pass --cc='distcc gcc' / --cxx='distcc g++' to configure when the distcc shim path is present. Falls back to plain gcc/g++ otherwise so a !distcc build is unaffected. Validated locally: distcc-avahi 3.4-19 on fermi exposes /usr/lib/distcc/bin/gcc -> ../../../bin/distcc, and the four-worker pool (tesla, dcc1, dcc2, boltzmann) is reachable via DISTCC_HOSTS=+zeroconf. Earlier ffmpeg builds on run 76 logged zero connections on any worker despite distcc-avahi being correctly installed — this is the missing piece.	2026-05-08 20:49:53 +00:00
Claude (noether)	89aad2d158	distcc-avahi: 3.4-19 — install /usr/lib/distcc/bin/ symlinks (closes #6) ... Mirror Arch upstream's /usr/lib/$pkgname/bin/<compiler> -> ../../../bin/distcc symlink farm in package(). Without it, makepkg's buildenv_distcc() check [[ -d /usr/lib/distcc/bin ]] fails, BUILDENV=(distcc ...) is silently a no-op, and aarch64 builds compile locally instead of distributing. Also keeps the legacy /usr/lib/$pkgname/<compiler> -> ../../bin/distcc flat layout that update-distcc-symlinks(1) used to produce, so distcc hosts using the Debian-style invocation continue to work. Drop the post_install/_warn_masq update-distcc-symlinks dance since the symlinks now ship in the package. Add pre_upgrade hook that strips untracked legacy symlinks from <= 3.4-18 so pacman can drop the new tracked ones in their place without a file conflict. Compiler set matches Arch upstream (c++ c89 c99 cc clang clang++ cpp g++ gcc, plus \$CHOST-{gcc,g++,gcc-\$(gcc -dumpversion)}).	2026-05-08 19:23:34 +00:00
test0r	8275642583	mpv-fourier pkgrel=8 + workflow: clear corrupt pacman cache before reinstall ... Run #73 hit: warning: ffmpeg-v4l2-request-fourier-... is up to date -- reinstalling File /var/cache/pacman/pkg/ffmpeg-v4l2-request-fourier-...pkg.tar.xz is corrupted (invalid or corrupted package (checksum)). The corrupt cached file is left over from the ccache misadventure that interrupted earlier builds mid-download. Pacman doesn't auto- redownload corrupt cached files in this code path. Add a targeted rm of cached ffmpeg-v4l2-request-fourier-*.pkg.tar.* before the install so the next pacman -S downloads fresh. Yak shave count for mpv-fourier-aarch64 to actually run: 6 (pkgrel→4 to outrank stock, [marfrit] config, ffmpeg-v4l2-request explicit dep, conflict-prompt acceptance, pipefail-friendly printf, cache rm). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 18:26:07 +00:00
test0r	042dffbe1d	mpv-fourier pkgrel=7 + workflow: printf instead of yes (SIGPIPE makes pipeline fail under pipefail) ... Run #70 actually succeeded at the pacman level (log shows ffmpeg removed and ffmpeg-v4l2-request-fourier installed) but the step exited non-zero. Cause: bash's set -o pipefail (Gitea Actions default) sees `yes` get SIGPIPE'd when pacman closes its stdin, yes exits 141, pipeline reports 141 → step fails. Replace `yes y | pacman -S ...` with finite-stream printf that exits 0 cleanly. Three y's cover all expected prompts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 17:52:26 +00:00
test0r	80bda4d679	mpv-fourier pkgrel=6 + workflow: pipe yes through pacman -S to accept swap ... Run #69 hit: ffmpeg-v4l2-request-fourier-2:... and ffmpeg-2:8.1.1-1 are in conflict. Remove ffmpeg? [y/N] error: unresolvable package conflicts detected pacman -S --noconfirm defaults [y/N] prompts to N and refuses the swap. Switch to `yes y | pacman -S ...` (without --noconfirm) to accept the conflict-removal prompt cleanly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 17:34:50 +00:00
test0r	a8e042cf2f	mpv-fourier pkgrel=5: build against marfrit ffmpeg-v4l2-request-fourier ... Run #68's mpv-fourier-1:0.41.0-4 fails to start on ohm with libavcodec ABI mismatch: build version 62.28.101 incompatible with runtime version 62.28.100 Build host (fermi) pulls stock arch ffmpeg via makepkg --syncdeps — that ffmpeg currently ships libavcodec 62.28.101. Consumer host (ohm) runs marfrit/ffmpeg-v4l2-request-fourier (Kwiboo's fork pinned to commit b57fbbe, libavcodec 62.28.100). The build/runtime drift silently aborts mpv at startup before the version banner prints. Fix: configure [marfrit] on fermi and pre-install our ffmpeg before makepkg --syncdeps. mpv-fourier PKGBUILD now depends on ffmpeg-v4l2-request-fourier explicitly (replacing the generic ffmpeg dep), making the build target unambiguous. Workflow change: new step in mpv-fourier-aarch64 between "install deploy ssh key" and "makepkg" — imports the marfrit signing key into pacman-key, appends [marfrit] block to /etc/pacman.conf if absent, syncs db, installs marfrit/ffmpeg-v4l2-request-fourier explicitly so makepkg --syncdeps finds the dep already satisfied via provides=ffmpeg. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 17:06:45 +00:00
test0r	9613cbbc9e	mpv-fourier pkgrel=4: outrank stock arch's pkgrel=3 so replaces= triggers on -Syu ... Stock arch ships mpv 1:0.41.0-3. Our 1:0.41.0-2 is OLDER per vercmp, so pacman -Syu refuses to apply replaces=mpv (no auto-downgrade across the replaces relation). Bump to pkgrel=4 to win the comparison. Going forward: when stock arch bumps mpv pkgrel, mpv-fourier needs a matching bump. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 15:30:54 +00:00
test0r	9cd7d0f047	mpv-fourier pkgrel=2: fix meson invocation to match stock arch ... Run #66 failed at meson setup with "Feature win32-threads cannot be enabled". Root cause: arch-meson defaults to --auto-features=enabled, which makes mpv's platform-specific features (win32-threads, etc.) required and fails the build on Linux. Stock arch's PKGBUILD passes --auto-features=auto explicitly to make features opt-in instead of required. Adopted stock arch's full meson_options block: --auto-features auto -Dlibmpv=true -Dgl-x11=enabled -Dcaca=disabled -Ddrm=enabled -Dcdda=enabled -Ddvbin=enabled -Ddvdnav=enabled -Dlibarchive=enabled -Dopenal=enabled -Dsdl2-audio=enabled -Dsdl2-video=enabled -Dsdl2-gamepad=enabled Also matched stock makedepends (added ladspa, vulkan-headers, dropped ninja/pkgconf which are pulled in transitively), added !emptydirs option, adopted the package() pkgconfig-cleanup + docs/scripts install pattern, added epoch=1 to match stock's versioning (so replaces= works cleanly). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 15:06:10 +00:00
test0r	375be40deb	add mpv-fourier scaffold (delivery vehicle for dmabuf-modifier-triage iter1) ... mpv on ohm is currently stock arch from [extra]. To ship the vo_dmabuf_wayland plane-semantics fix per marfrit/dmabuf-modifier-triage#1, we need an mpv-fourier package following the same fourier-umbrella pattern as kwin-fourier, qt6-base-fourier, firefox-fourier, libva-v4l2-request-fourier. This commit lays down: - arch/mpv-fourier/PKGBUILD pinning upstream mpv 0.41.0 tarball, with empty patch slot in prepare(). replaces=mpv. provides=mpv,libmpv.so. When iter1 produces the patch, add it to source=()/sha256sums=() and uncomment the patch -p1 line. - arch/mpv-fourier/README.md documenting why + tracker links - .gitea/workflows/build.yml job mpv-fourier-aarch64 chained after libva-v4l2-request-fourier-aarch64 for marfrit.db serialization. Same fermi LXC runner, same makepkg → sign → repo-add → rsync flow. Initial scaffold builds vanilla mpv 0.41.0 with no fourier patches — once iter1 lands, bump pkgrel and add the patch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 14:48:03 +00:00
test0r	65cf701b75	add libva-v4l2-request-fourier package + Gitea Actions job ... Production-tip successor to the experimental libva-v4l2-request-ohm-gl-fix (tarball + 18-patch stack, never published). Tracks the libva-multiplanar campaign fork's git history directly via git+commit pin, so iteration sweeps land in a clean linear log instead of a growing patch stack. Pinned commit 65969da3 = libva-multiplanar iter8 close (last commit on master before fresnel-fourier work began layering MPEG-2 rewrites on top 2026-05-08). Promote to a later pin only after a future iteration closes cleanly. Workflow job mirrors ffmpeg-v4l2-request-aarch64 (same fermi LXC runner, same makepkg → sign → repo-add → rsync-to-nc.reauktion.de pattern), and chains via needs: ffmpeg-v4l2-request-aarch64 to serialize marfrit.db updates. nasm dropped from bootstrap (libva has no x264-style asm). replaces=(libva-v4l2-request libva-v4l2-request-ohm-gl-fix) covers both stock Arch and locally-installed predecessor copies; predecessor was never published so no marfrit.db collision. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 12:33:24 +00:00
marfrit	59bb02709f	distcc-avahi: 3.4-18 — fix DISTCC_ARGS/DISTCC_OPTS drift on upgrade (closes #5) ... Stock distcc and earlier distcc-avahi releases ship /etc/conf.d/distccd with DISTCC_ARGS=, while our distccd.service reads $DISTCC_OPTS. On hosts that had stock distcc installed first, pacman keeps the existing conf file (it's marked backup=) so the rename never happens — distccd starts with empty options, falls back to --allow-private, and warns about missing /usr/lib/distcc masquerade dir. Add a post_install/post_upgrade .install hook that: - detects DISTCC_ARGS= in /etc/conf.d/distccd and renames to DISTCC_OPTS= (keeping a timestamped backup beside it) - runs update-distcc-symlinks if /usr/lib/distcc is unpopulated - prompts the operator to restart distccd if it's already active Bumps pkgrel to 18. Hit on ampere 2026-04-29 during fourier-campaign distcc enrollment; likely lurking on every host with stock-distcc legacy state.	2026-05-02 23:33:45 +00:00
marfrit	beebeb6c65	claude-his-agent v0.2.0: split — public framework only, private runbook fetched at install ... The previous package bundled the agent prompt + skill cheatsheet, which leaked home-infra topology (specific hosts/IPs, plug AINs, /opt/herding cred file paths, kid/2FA context) to anyone with the public APT/pacman repo URL. v0.2.0 ships only the plumbing: - /usr/bin/claude-his-fetch (rsync runbook from $HIS_CONTEXT_HOST over SSH) - /usr/bin/claude-his-install (symlinks cache -> ~/.claude/) - /usr/share/doc/claude-his-agent/README.md Runbook content lives at $HIS_CONTEXT_HOST:/opt/his-context/ (default hertz) and gets fetched into ~/.cache/claude-his-agent/ on install. SSH key auth is the trust boundary. Adds rsync + openssh-client as runtime deps. Upstream sha256: c39dd1a956d303ac2417498dde05ac923bf686f1fc978f78f0d63ca42432b8b8	2026-05-02 15:48:04 +00:00
test0r	b47938e0bc	Add libva-v4l2-request-ohm-gl-fix package ... Mirrors phase6/step1/ from the ohm_gl_fix campaign. Contract-correct hantro multi-planar / chromium-149-era stateless H.264 port of bootlin's libva-v4l2-request, patches 0001..0018 + fourier-local. Honest characterisation in README: - Builds cleanly on chromium-builder LXC (boltzmann) - vainfo enumerates H.264 profiles cleanly with LIBVA_DRIVER_NAME=v4l2_request - NOT on Brave's decode path on ohm_gl_fix stack — Brave uses Chromium's own V4L2VideoDecoder in media/gpu/v4l2/. - Most likely useful for a future Firefox-via-libavcodec-vaapi campaign, modulo a separate Mesa-panfrost WSI pitch issue. - DEBUG patches (0010, 0011, 0014) intentionally kept in series for development; remove for cleaner production runs. Audit trail in the source repo at ohm_gl_fix: phase6/step1/audit_0008_decode_params_2026-05-01.md phase6/step1/api_contract_findings_2026-05-01.md phase3_remeasure_2026-05-02/B3_decoder_discovery.md (why this isn't on Brave's path)	2026-05-02 15:17:10 +00:00
test0r	7a5ec202ff	kwin-fourier, qt6-base-fourier: detach upstream-tarball name from pkgname ... After the rename, source URLs and extracted-dir refs that used $pkgname-$pkgver were producing kwin-fourier-6.6.4.tar.xz etc. which KDE doesn't ship. Use a separate _upname/hardcoded value for the upstream artifact. kwin-fourier: introduce _upname=kwin, use everywhere the upstream dir/tarball name is referenced (source URL, prepare patch -d, cmake -S) qt6-base-fourier: $_pkgfn=${pkgbase/6-/} produced 'qtbase-fourier' with the rename. Hardcode _pkgfn=qtbase.	2026-04-30 05:31:23 +00:00
test0r	65b3919800	rename campaign packages to use -fourier suffix ... Stock-replacing pkgnames (kwin, qt6-base) hid the campaign carry from 'yay -Sl | grep fouri'. Renamed to -fourier suffix everywhere, with conflicts/provides/replaces so existing stock installs auto-migrate on next pacman -Syu. Pkgrel bumped on each. kwin -> kwin-fourier qt6-base -> qt6-base-fourier qt6-xcb-private-headers -> qt6-xcb-private-headers-fourier ffmpeg-v4l2-request-git -> ffmpeg-v4l2-request-fourier vulkan-panfrost -> vulkan-panfrost-fourier	2026-04-30 05:30:02 +00:00
test0r	bc2c97d16e	kwin-fourier: revert active patch to 0001, bump to pkgrel=2 ... 0002's upstream-shape patch turned out to be semantically equivalent to stock (sync_file snapshots fences at export, polling the dmabuf fd tracks later-added fences — the patch swaps one ioctl for one F_DUPFD with a behaviour change Mutter explicitly moved away from on amdgpu). Hosts running 0002 are effectively stock and stall during V4L2 stateless playback because the producer doesn't populate dma_resv exclusive fences, so the sync_file is a stub and KWin waits forever. 0001 (bypass the watchDmaBuf wait entirely) is the working downstream carry. Trade-off is that frames can present before the producer signals, but on V4L2 stateless hardware where no fence is populated at all, there's nothing to wait for in practice. Upstream fix lives in the linux-media RFC (vb2 dma_resv producer fences, sent 2026-04-29). Once that lands and producer drivers opt in, the 0001 carry can be retired and the upstream-shape 0002 reconsidered. Both patches stay on disk; 0002 is not being upstreamed (MR 9157 closed on reviewer feedback).	2026-04-30 04:59:37 +00:00
test0r	3b453de45a	upstream-submissions/fourier-campaign: YouTube HW decode delivery plan ... Full state-of-play matrix (browser × SoC × codec) plus per-SoC ranked-by-tractability YouTube delivery paths, drafted by the Plan subagent with web research synthesizing LibreELEC/CoreELEC patterns, Mozilla bugzilla, Collabora's mainline Rockchip status, and chromium-dev threads. Sources cited at the end. Headline: - fresnel ships today via enhanced-h264ify forcing YouTube to serve H.264 (rkvdec already validated bbb_1080p30 RDD 78% to 5%) - ohm needs VP9 hwaccel verification against hantro before claims - ampere blocked on Linux 7.0 / VDPU381 rkvdec2 driver kernel rebase - mpv-as-YouTube is the LibreELEC-inspired browser-bypass path Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 21:56:12 +00:00
test0r	e9b5252314	tools/lore-watch.sh: also watch dri-devel and linux-rockchip ... Christian König (DMA-buf maintainer) tends to reply on dri-devel. Rockchip SoC people land on linux-rockchip. Adding both to the watched-inbox list, generalized the loop so the array is the only thing to edit when adding more. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 20:12:37 +00:00
test0r	8ffe95470c	tools/lore-watch.sh: daily monitor for replies on linux-media public-inbox ... Polls https://lore.kernel.org/linux-media/0 over the public-inbox git protocol (bypasses Anubis JS-PoW that the lore web UI now ships), walks new commits since last seen, mails any messages whose headers reference mfritsche@reauktion.de via msmtp. Cron entry on noether (manual install): 43 8 * * * Started 2026-04-29 to track the vb2 dma_resv RFC series. Other upstream threads (KWin MR, QtBase, ffmpeg-v4l2-request) live on non-lore venues and are tracked separately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 20:00:39 +00:00
test0r	6c50354afb	upstream-submissions/kwin-fourier: add subjective field-use note ... User has been running the more aggressive 0001 variant (skip the watchDmaBuf wait entirely) downstream and reports Plasma feels measurably snappier — fewer latency spikes under heavy compositor activity. The present 0002 MR has different (correct) wait semantics so the perceived gain can't be directly attributed, but calling it out gives reviewers an honest signal that the patch at least preserves whatever benefit was on the table downstream. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 19:19:06 +00:00
test0r	70a01bd41a	upstream-submissions/kwin-fourier: validation findings + revised MR body ... Captured stock kwin 6.6.4 ioctl baselines on ohm (PineTab2 / RK3566 / mainline 6.19.10 / Plasma 6.6.4 Wayland): - Brave + bbb 1080p30 (sw decode), 60 s: 96,120 ioctls, 0 EXPORT_SYNC_FILE - chromium-fourier + bbb 1080p30, 30 s: 29,128 ioctls, 0 EXPORT_SYNC_FILE, ~7,800 SYNCOBJ_* (explicit sync) Finding: KWin 6.6.4 + drm-syncobj-aware clients negotiate wp_linux_drm_syncobj_v1 explicit sync, leaving Transaction::watchDmaBuf on the legacy implicit-sync path that fires only for clients that don't advertise drm-syncobj support. Updated kde-mr-body.md to reflect honest scope: structural cleanup of the legacy path (still relevant for older clients / V4L2 pipelines that don't wrap dmabufs in syncobjs) rather than the originally- hypothesized per-frame ioctl reduction. Patch is correct by construction; no regression on the no-targeted-path workload. Evidence files saved under measurements/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 19:10:55 +00:00
test0r	00aa186b99	arch/kwin-fourier: switch active patch to upstream-shape 0002 ... 0002-transaction-poll-dmabuf-fd-directly-upstream-shape.patch is the form we'll be sending to invent.kde.org/plasma/kwin (see upstream-submissions/kwin-fourier/kde-mr-body.md). Same observable behavior as 0001 (skip the EXPORT_SYNC_FILE round-trip), cleaner shape: dup() the dmabuf fd and hand it to TransactionFence directly instead of bypassing the wait entirely. 0001 is kept on disk for reference; carry could revert to it if the upstream-shape MR runs into review issues. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 18:41:48 +00:00
test0r	7183f16961	upstream-submissions/firefox-fourier: bugzilla 1969297 comment draft ... Independent firefox-fourier campaign (RK3399 H.264 stateless via rkvdec) overlaps significantly with David's HEVC work outlined in comment #3 — same gfxinfo / FFmpeg / sandbox plumbing. Posting our findings, including a non-obvious sandbox/libudev interaction (Mozilla's OpenAtTrap rejects fd-relative openat used by systemd's chase() inside udev_enumerate_scan_devices), would save duplicate effort. Draft is the proposed comment text plus upload notes. Final submission still needs human review + bugzilla account to post. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 18:14:36 +00:00
test0r	052a692668	ffmpeg-v4l2-request-git: libudev bypass for sandboxed callers ... Adds a brute-force fallback to v4l2request_open_decoder() that enumerates /dev/media[0..15] and /dev/video[0..63] directly when udev_enumerate_scan_devices() returns an error. The fallback uses absolute paths only (no fd-relative openat), which is what makes it work inside firefox's RDD seccomp+broker sandbox where Mozilla's OpenAtTrap rejects fd-relative paths used by systemd's chase() symlink resolver. Same approach Chromium uses in media/gpu/v4l2/stateless/ on ChromeOS, where the sandbox similarly forbids libudev's chase pattern. No regression: the libudev path runs first and the brute-force path only activates on its failure. AV_LOG_INFO line announces the fallback so it's visible in MOZ_LOG=FFmpegLib:5. Validated on RK3399 / Pinebook Pro / rkvdec: libudev probe failed (-2), falling back to brute-force /dev/media* Using V4L2 media driver rkvdec (brute-force) for S264 Reinit context to 1920x1088, pix_fmt: drm_prime RDD CPU = 4.9% Bumps pkgrel=2. Worth submitting to Kwiboo's fork upstream. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 17:58:57 +00:00
test0r	d0190e2c05	firefox-fourier: 0005 RDD sandbox carve-out for V4L2 stateless decode ... Extends Mozilla's RDD sandbox to permit /dev/media* (driver-matched), the MEDIA_IOC_* ioctl family ('|'), and the sysfs paths libudev would need to enumerate the media controller (read-only AddTree on /sys/class, /sys/bus, /sys/dev/char, /sys/devices/platform plus /run/udev, /etc/udev/udev.conf, /proc/self, /dev/dma_heap). Necessary but not sufficient on its own: Mozilla's OpenAtTrap rejects fd-relative openat used by systemd's chase() inside libudev. The companion ffmpeg-v4l2-request-git patch adds a brute-force fallback that opens /dev/media[0..15] directly with absolute paths, which composes with this broker policy. Validated on RK3399 / Pinebook Pro / mainline rkvdec: with both patches in place, default RDD sandbox runs HW decode at ~5% CPU on 1080p30 H.264 (vs ~64% software fallback before). Closes the parity gap with MOZ_DISABLE_RDD_SANDBOX=1 baseline. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 17:58:57 +00:00
marfrit	e0c1816ff4	claude-his-agent: bump to v0.1.9 (closes marfrit/claude-his-agent#1 #2 #3)	2026-04-29 10:02:44 +02:00
marfrit	047ed13e3d	firefox-fourier patch 3: regenerate canonical diff with corrected hunk arithmetic ... Earlier todays edit on patch 3 (commit e0af915) replaced the hw_configs-only sanity check with the dual-mechanism (named codec first, hw_configs fallback) probe. The patch text body was correct but the unified-diff hunk header at the .cpp portion still claimed the original +105-line content while the new content was 130 lines — so patch -p1 failed with malformed-patch errors. This commit regenerates the .cpp portion canonically via diff -u from the boltzmann working tree (which has the corrected logic applied). The .h portion is unchanged. Patch description body updated to match the new dual-mechanism behavior. Empirical evidence the new logic is correct lives in the boltzmann build; this commit just makes the patch file replay correctly from scratch.	2026-04-28 22:12:57 +00:00
marfrit	e0af915788	firefox-fourier patch 3: probe v4l2_request via codec name first ... Diagnostic on fresnel (RK3399 / Mali-T860 / mainline) showed InitV4L2RequestDecoder running at runtime but failing the hw_configs sanity check: FFMPEG: Initialising V4L2 stateless (request API) FFmpeg decoder FFMPEG: codec h264 has no DRM hwaccel — libavcodec built without --enable-v4l2-request? FFMPEG: Initialising V4L2-DRM FFmpeg decoder ← falls through to stateful FFMPEG: V4L2 codec h264_v4l2m2m : V4L2 mem2mem H.264 decoder wrapper FFMPEG: Couldn't initialise V4L2 decoder ← stateful also fails …despite the system libavcodec.so being built with --enable-v4l2-request and exposing h264_v4l2request, vp8_v4l2request, etc. as named AVCodec entries. Root cause: libavcodec exposes v4l2_request through one of two mechanisms depending on the build: (a) Named AVCodec entry (legacy, distro-portable): looked up via avcodec_find_decoder_by_name("h264_v4l2request"). ALARM, Debian, most distros use this. (b) hw_configs entry on the generic codec (modern, upstream): the generic codec's AVCodecHWConfig array advertises AV_HWDEVICE_TYPE_DRM. Setting hw_device_ctx binds the hwaccel. Patch 3 originally only probed (b). On builds that ship (a) — the common case — the check failed even though v4l2_request was fully functional. Fix: probe (a) first via the codec-name lookup table, fall back to (b) walking hw_configs. Both shapes work; the decoder is opened with whichever AVCodec the probe selected. The DRM hwdevice ctx attachment is unchanged (both mechanisms need it for surface allocation). Patch description and the in-code comment block updated to document the dual mechanism. Behaviour on stateful-only boards (Pi4 / vendor MPP) preserved: neither named codec nor hw_configs DRM is registered, the function bails out, the existing InitV4L2Decoder runs as before.	2026-04-28 21:59:01 +00:00
marfrit	a1dc662c39	upstream-submissions: top-level README ... Index README for upstream-submissions/. Captures: - Directory layout (3 subdirs, one per series). - Where the actual patch files live. - Submission status table (none filed yet). - Validation gates common to all three series. - Recommended submission order: vb2-dma-resv first (the architectural correction the kwin patch's premise depends on), qt6-base-fourier independently anytime, kwin-fourier last with reference to the merged/in-flight kernel patch. - Cadence after submitting: review feedback loop, LTS backport requests, eventual retirement of the local -fourier packages once the upstream changes ship.	2026-04-28 19:54:06 +00:00
marfrit	d3564b061c	upstream-submissions/vb2-dma-resv: linux-media submission notes ... Submission notes for the kernel/vb2-dma-resv-rfc series. Captures: - Pre-flight gates (full-tree compile-test, boot-test on ohm, runtime validation by uninstalling kwin-fourier and confirming chrome still plays through, syscall-count delta). - The git send-email recipe with the full CC list (linux-media, V4L2 maintainers, hantro maintainer Tomasz Figa, dma-buf reviewers Sumit Semwal / Christian König / Jason Ekstrand, dri-devel, linux-rockchip, Heiko / Jeffy). - Expected reviewer feedback (opt-in vs. auto-on, selftest request, signal-point semantics for async producers, Pick-to-LTS decision). - Withdraw conditions if upstream is already doing this work or the design has a fundamental issue we didn't see. This is the third upstream-submission draft in the campaign: upstream-submissions/qt6-base-fourier/ bugreports.qt.io draft upstream-submissions/kwin-fourier/ invent.kde.org MR draft upstream-submissions/vb2-dma-resv/ linux-media draft (this)	2026-04-28 19:52:02 +00:00
marfrit	92b9c91bd3	upstream-submissions/kwin-fourier: invent.kde.org MR body draft ... KDE merge-request body for kwin-fourier patch 0002 (the upstream-shape, not the diagnostic 0001 bypass). Captures: - Summary of the change (poll dmabuf fd directly, drop the EXPORT_SYNC_FILE+sync_file roundtrip). - Why it matters (per-frame ioctl overhead on Mali hardware, measurable contributor to compositor latency spikes). - Side effects (drop unused linux/dma-buf.h and xf86drm.h includes, remove exportWaitSyncFile static helper). - Alternative considered (16ms timeout — preserves shape but doesn't remove the syscalls; rejected for that reason). - Validation context on PineTab2. - Future work pointer at the kernel-side dma_resv work. - KDE contribution flow boilerplate: account, SSH, fork+branch recipe, reviewer suggestions (vladz, zamundaaa, David Edmundson), labels (Component::Wayland, Performance, Backport). Validation gate before submitting: build kwin-fourier with 0002 instead of 0001, install on ohm, confirm equivalence with the 0001-validated playback. Strace numbers for the syscall reduction go into the MR body once captured. This is a parallel to the qt6 submission draft committed earlier.	2026-04-28 19:50:44 +00:00