78 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
marfrit	97b9a80e3c	upstream-submissions/qt6-base-fourier: bugreports.qt.io draft ... Bug-report body for filing the qt6-base-fourier patch series at bugreports.qt.io against QtBase: OpenGL. Captures: - The summary (GL_ALPHA hard-coded for QT_CONFIG(opengles2), spec-violating in OpenGL ES 3.x). - Reproduction steps (any Mali-class hardware running Plasma Wayland + Qt 6, watch the journal for kwin_wayland's GL debug output). - The four affected sites in qtbase (qopengltextureglyphcache.cpp ×2, qrhigles2.cpp, qopengltextureuploader.cpp). - The fix shape and the runtime predicate added by each patch. - Validation context on ohm (RK3566 PineTab2, mainline 6.19, panfrost mesa 26.0.5). - Gerrit submission boilerplate: account setup, per-patch trailers (Bug:, Pick-to:, Change-Id), reviewer suggestions. The patches themselves stay in arch/qt6-base-fourier/ unchanged — the Change-Id and Bug: trailers will be added at submission time once the bug is filed and bugreports.qt.io issues an issue number. The patches are commit-message-ready to upload via git-review master once those trailers land.	2026-04-28 19:49:35 +00:00
marfrit	3cecf6f430	arch/kwin-fourier: mirror the upstream-shape patch ... Mirror github.com/marfrit/fourier kwin-fourier/0002 + README update to the local Arch package source. PKGBUILD unchanged — still applies 0001 (the diagnostic bypass). The 0002 patch (poll dmabuf fd directly, drop the EXPORT_SYNC_FILE + sync_file roundtrip) is staged for validation; when validated, swap the source array entry in PKGBUILD from 0001 to 0002 and rebuild.	2026-04-28 19:41:38 +00:00
marfrit	5e68aec2e9	kernel/vb2-dma-resv-rfc: regenerate via git format-patch + verify ... Replace the hand-rolled draft patches with the proper git-format-patch output. The new files apply cleanly via git am against unmodified Linux 6.12 mainline, verified by reset-and-apply roundtrip on /tmp/hantro-src (the local sparse checkout used during the chromium-fourier campaign). All kernel API calls also sanity-checked against the real include/linux/dma-fence.h and include/linux/dma-resv.h signatures: - dma_fence_init(fence, ops, lock, context, seqno) — argument list matches our call exactly - dma_resv_add_fence(obj, fence, usage) — DMA_RESV_USAGE_WRITE enum value confirmed present - dma_fence_signal, dma_fence_set_error, dma_fence_get, dma_fence_put, dma_fence_context_alloc — all present and correctly used - dma_resv_lock(obj, NULL), dma_resv_unlock — present, correctly paired README updated to reflect the post-verification status. Remaining gates before sending to linux-media are now: full-tree compile test (needs complete kernel checkout, hours of work), boot test on ohm (needs patched kernel build), and the runtime A/B (install patched kernel + uninstall kwin-fourier — chrome should still play 1080p30 because the fence is now real). Cover letter blurb filled in with the full motivation, test setup, and review-question list.	2026-04-28 19:29:05 +00:00
marfrit	a7892bfabc	kernel/vb2-dma-resv-rfc: 3-patch RFC series draft ... Drafted but not yet compile-tested or runtime-validated. Draft target: vb2 grows an opt-in dma_resv release-fence API; hantro and rockchip-rga opt in as the demonstration drivers. Series structure: - 0000-cover-letter.patch — context, motivation, validation results - 0001-media-videobuf2-add-dma_resv-release-fence-helper.patch Adds vb2_buffer_attach_release_fence() that drivers call from their buf_queue callback. Stores the fence on vb->release_fence; vb2_buffer_done signals + puts. Per-queue fence context allocated at vb2_core_queue_init. - 0002-media-hantro-attach-dma_resv-release-fence-at-buf_queue.patch Single call in hantro_buf_queue. ~5 lines. - 0003-media-rockchip-rga-attach-dma_resv-release-fence-at-buf_queue.patch Same shape in rga_buf_queue. ~5 lines. Pre-flight before sending to linux-media (per kernel/README.md): 1. Compile the touched files against the kernel tree the patches will land on (linux-next master as of 2026-04-28 was the source of truth used for context-line generation). 2. Boot-test on ohm, smoke-test hantro + rga buffer flows. 3. Validate the fence semantics: install patched kernel, uninstall kwin-fourier so KWin's watchDmaBuf is active, play 1080p30 H.264 under KDE Plasma — should plays through without the bypass because the fence is now real. 4. Capture before/after dma_buf_export_sync_file timings. 5. Send via git format-patch --cover-letter to linux-media@, CC dri-devel@ and the relevant maintainers. This series is the kernel-correct fix for the architectural hole that the chromium-fourier campaign's kwin-fourier package is papering over. With this kernel side upstream, kwin-fourier becomes either redundant (if KWin's existing wait works correctly) or rewritten as a poll-fd-direct optimization.	2026-04-28 19:13:40 +00: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	84088141fd	kwin-fourier: bypass watchDmaBuf implicit-sync fence wait (experiment) ... Hypothesis under test: KWin's Transaction::watchDmaBuf calls DMA_BUF_IOCTL_EXPORT_SYNC_FILE on every plane of every imported dmabuf and parks the transaction on a QSocketNotifier(POLLIN) waiting for that sync_file. On V4L2 hantro CAPTURE buffers (RK3566 mainline 6.19, panfrost mesa 26.0.5) the resulting fence either never signals or signals so late that chrome's 6-buffer V4L2 capture pool exhausts at ~6s, hard-stalling the decoder. mpv with gpu-next slideshows at 76% drop. weston A/B with same chrome v4 binary plays through clean — KWin's watchDmaBuf is the suspect. This experiment patches watchDmaBuf to no-op. Wayland clients are required by spec to ensure buffer contents are complete before wl_surface.attach+commit, so the fence-wait is a defensive optimization for misbehaving clients, not a correctness primitive. If chrome plays through end-to-end at the recorded 34.7% combined CPU number with this patched KWin, the bug is confirmed and the upstream fix can be refined (timeout, V4L2-source skip, or use the dmabuf fd directly in the QSocketNotifier instead of an extra exported sync_file). KWIN_PIVOT.md (in chromium-fourier/) carries the discovery thread.	2026-04-28 17:11:04 +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	1dada5122b	qt6-base-fourier: GL_ALPHA → GL_R8 on OpenGL ES 3.x ... Three small runtime checks in qtbase 6.11.0: 1. src/opengl/qopengltextureglyphcache.cpp createTextureData() and load_glyph_image_to_texture() — the `#else` branch (active when qtbase is built with QT_CONFIG(opengles2), every aarch64 distro) hard-codes GL_ALPHA without checking the runtime context's ES version. Replace with `useR8 = ctx->format().majorVersion() >= 3` so ES 3+ contexts get GL_R8 + GL_RED. 2. src/gui/rhi/qrhigles2.cpp toGlTextureFormat() RED_OR_ALPHA8 case — gated only on caps.coreProfile. Extend with `caps.gles && caps.ctxMajor >= 3`. 3. src/opengl/qopengltextureuploader.cpp Format_Alpha8 and Format_Grayscale8 cases — short-circuit on `context->isOpenGLES()` before reaching the swizzle fallback. Restrict to ES 2 only so ES 3+ falls through to the existing TextureSwizzle path. Discovered while validating chromium-fourier patch 3/3 (NV12 EXTERNAL_OES) on ohm. The chrome stall, VLC vout init failure and mpv "could not initialize video chain" all share this Qt 6 root cause: every Qt application running on Mali / panfrost / panthor under a KWin Wayland session emits glTexImage2D(GL_ALPHA) on every text-glyph cache upload, mesa returns GL_INVALID_VALUE, the compositor's frame-callback path stalls, and every wayland video client deadlocks behind it. PKGBUILD inherits from extra/qt6-base 6.11.0-2 with arch+=aarch64, epoch=1 to dominate Arch's pkgrel until upstream lands the fix. qt6-base-cflags.patch and qt6-base-nostrip.patch carried verbatim from upstream packaging. KWIN_PIVOT.md (in chromium-fourier/) carries the full diagnosis thread.	2026-04-28 12:35:08 +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
test0r	9994c4e3b6	arch/ffmpeg-v4l2-request-git: FFmpeg 8.1 + V4L2-Request hwaccel for Fourier ... First carrier package for the Fourier umbrella. Tracks Kwiboo's v4l2-request-n8.1 branch (ffmpeg 8.1 base) pinned at commit b57fbbe — bump _commit to rebase onto newer tip. CI job chained after claude-his-any so it serializes on the shared aarch64 repo-db; continue-on-error: true so long ffmpeg builds don't block the debian downstream. Deliberately diverges from the AUR package: - AUR pins 6.1.1 with epoch=2 → would downgrade stock Arch ffmpeg 2:8.1-3. We track 8.1 so install is a sideways swap, not a regression. - AUR pulls X11/AMF/CUDA/FireWire/AviSynth/OpenMPT/Bluray/OpenMAX/JPEG-XL/ Theora/XVid/rsvg/soxr/ssh/vidstab/modplug/SDL2/Vulkan/JACK/GSM/Speex — dropped here; none are needed on a Wayland ARM video-decode fleet. - AUR uses #branch=…, sha256sums=(SKIP) → every build is tip-of-branch, not reproducible. We pin via #commit=<sha>. Kept: encoders (libx264/libx265/libvpx/libdav1d), VAAPI, libdrm, libv4l2, neon, OpenGL, PulseAudio, subtitle/font stack, gnutls TLS. SDL2 dropped means no ffplay binary (mpv covers interactive playback). provides=(ffmpeg) conflicts=(ffmpeg) so it replaces stock ffmpeg on the target host deliberately. Primary consumers: ohm (Fourier step 5), fresnel, ampere.	2026-04-24 20:03:16 +00:00
test0r	23fa4376ff	claude-his-agent: bump to v0.1.8 (document /opt/herding/etc cred paths)	2026-04-24 15:18:06 +02:00
test0r	1b0b609ae7	lmcp 0.5.4: ship lmcp.service systemd unit template	2026-04-21 22:23:54 +02:00
test0r	0a58b1e14f	lmcp 0.5.3: bump build-deb.sh PKGVER+sha (forgot earlier)	2026-04-21 16:11:54 +02:00
test0r	00ba627373	lmcp 0.5.3: fix sha256 (previous hash was of 404 error page due to private repo flag)	2026-04-21 15:38:47 +02:00
test0r	c07d1f846c	lmcp 0.5.3-1: hub hardening — hard ssh timeout, parallel probes, sticky DOWN cache	2026-04-21 14:00:28 +02:00
test0r	ef7911dd27	distcc-avahi: fix FORTIFY buffer overflow in dcc_gcc_rewrite_fqn ... pkgrel 16 builds ship an upstream distcc 3.4 bug: src/compile.c sizes the rewritten-compiler-name buffer with strlen(argv[0] + 1) — pointer arithmetic applied before strlen — under-allocating by 2 bytes. glibc FORTIFY_SOURCE=2 catches the resulting overflow in strcat and aborts, so every "distcc gcc ..." invocation dies on a modern Arch. Patch moves the +1 outside the strlen, as intended. Closes marfrit/marfrit-packages#3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 12:02:38 +02:00
test0r	2ebaf04c47	lmcp: bump to v0.5.2 (shell_bg + remote_shell_bg) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 11:34:48 +02:00
test0r	a91516df60	claude-his-agent: bump to v0.1.7 (Gitea bug-filing convention) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 11:32:49 +02:00
test0r	a4182851ed	lmcp: bump to v0.5.1 (search_files BSD find symlink fix) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-19 14:48:27 +02:00
test0r	d02dfdbfa0	lmcp: bump to v0.5.0 (hub broker + examples) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-19 14:30:03 +02:00
test0r	9ce6943575	ci: add 3-try retry wrappers to network-facing steps ... Observed two flakes in 24h — distcc-avahi-aarch64 at 66a7050 and lmcp-any at 22060e0. Journal for both showed the job starting then failing silently before any sudo/makepkg line. Theory: transient pacman mirror sync failures on \"pacman -Syu --needed\" in the bootstrap steps, with the rsync-to-nc step as secondary exposure (IPv6 prefix rotations from the Fritz reconnect cron are visible in the runner journal). Wrap pacman -Syu (5 sites), rsync to nc and hertz (5 sites), and ssh publish-deb (2 sites) in a tiny 3-try exponential-backoff retry helper defined per-step. No workflow restructure, no job-graph changes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-19 10:32:24 +02:00
test0r	6a97649c1d	claude-his-agent: bump to v0.1.6 (pump-mode runbook note) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-18 22:00:56 +02:00
test0r	1e884d74c0	claude-his-agent: bump to v0.1.5 (+zeroconf in DISTCC_HOSTS) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-18 21:37:28 +02:00