289 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
claude-noether	1414dfeac2	.gitea/workflows: add libvulkan-dev + glslang-tools to daedalus-v4l2 Debian build deps ... The daedalus-v4l2 build-deb.sh (post marfrit-packages#72) now fetches + cmake-builds daedalus-fourier into a per-build temp prefix before building the daemon, so the static-archive can be linked in. daedalus-fourier's CMakeLists requires Vulkan headers and glslangValidator (for SPIR-V compilation of the .comp compute shaders). Without them the configure step on the debian-aarch64 runner fails with: CMake Error at FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR) (Observed on Gitea Actions run 1056.) Add `libvulkan-dev` and `glslang-tools` to the apt-get install line so the in-build daedalus-fourier compile succeeds and the daemon can link.	2026-05-21 19:58:19 +02:00
marfrit	41c1e0b6b9	Merge pull request 'daedalus-v4l2: 5d8b436 -> 77e14e5 — #12 (LOW_DELAY) + #13 (daedalus-fourier linkage)' (#72) from claude-noether/marfrit-packages:noether/daedalus-bump-77e14e5-with-fourier into main ... Reviewed-on: #72	2026-05-21 17:15:12 +00:00
claude-noether	c9a4b82f2c	daedalus-v4l2: 5d8b436 -> 77e14e5 — picks up #12 (LOW_DELAY) + #13 (daedalus-fourier linkage) ... Daemon-only bump (no daedalus-v4l2-dkms change needed; PROTO_VERSION stays at 0). #12 (LOW_DELAY half-measure): daemon sets AV_CODEC_FLAG_LOW_DELAY on the H.264 AVCodecContext so libavcodec emits frames in decode order ~99% of the time (a few stragglers at GOP boundaries when the stream's SPS num_reorder_frames overrides the flag). Visible improvement vs the 2-1-4-3 pair-swap on Firefox + mpv playback; not the permanent fix — see daedalus-v4l2#11 for the architectural plan to substitute daedalus-fourier kernels for libavcodec's pixel math one cycle at a time. #13 (daedalus-fourier linkage): daemon now pkg-config-links against the daedalus-fourier kernel library (marfrit/daedalus-fourier) and logs substrate availability at startup. No kernels dispatched yet — this is the build-time foundation for the substitution work. build-deb.sh updated to fetch + build + install daedalus-fourier (pinned at d87239d, marfrit/daedalus-fourier PR #1) into a per- build temp prefix before invoking the daemon's cmake, exposing it via PKG_CONFIG_PATH. Static-linked, so the resulting .deb has no new runtime deps. Requires libvulkan-dev + glslang-tools on the CI runner. Arch PKGBUILD bumped to the same upstream commit but Arch packaging for daedalus-fourier itself is a follow-up; until that lands the Arch build expects daedalus-fourier installed by the user (AUR-style). Debian-side is end-to-end self-contained via build-deb.sh. Refs: * reauktion/daedalus-v4l2#12 * reauktion/daedalus-v4l2#13 * reauktion/daedalus-v4l2#11 * marfrit/daedalus-fourier#1	2026-05-21 18:39:22 +02:00
marfrit	736b6da176	Merge pull request 'daedalus-v4l2{,-dkms}: 79256dc/6ffe92b -> 5d8b436 — revert parking design' (#71) from claude-noether/marfrit-packages:noether/daedalus-revert-bump-5d8b436 into main ... Reviewed-on: #71	2026-05-21 14:54:18 +00:00
claude-noether	34972ae9c1	daedalus-v4l2{,-dkms}: 79256dc/6ffe92b -> 5d8b436 — revert parking design ... Lock-step downgrade of both packages to the revert tip of daedalus-v4l2 (PR #10 closed PRs #7 + #8). After 0.1.0+r28+g79256dc-1 / 0.1.0+r30+g6ffe92b-1 landed in production, mpv (--hwdec=vaapi-copy) failed pre-playing with "Unable to dequeue buffer: Resource temporarily unavailable" because the daemon parked CAPTURE buffers waiting for libavcodec's display-order reorder, violating libva's V4L2 stateless 1:1 contract. See daedalus-v4l2#9 for the diagnostic, #10 for the revert PR. DAEDALUS_PROTO_VERSION drops 1 → 0; install both .debs in the same apt transaction. Userspace ABI returns to the f0d4186-equivalent behaviour, plus PR #4 (cosmetic H.264 menu controls). The daedalus-v4l2-dkms #64 multi-kernel postinst behaviour stays in build-deb.sh. Visible regression: H.264 B-frame streams in Firefox return to the "2 1 4 3 6 5" pair-swap visual. Proper fix (concurrent in-flight requests in daemon + display-order reorder moved into libva-v4l2- request-fourier) tracked at daedalus-v4l2#11. Refs: * reauktion/daedalus-v4l2#9 * reauktion/daedalus-v4l2#10 (merged) * reauktion/daedalus-v4l2#11	2026-05-21 15:42:03 +02:00
marfrit	a9f1b833b9	Merge pull request 'mesa-panvk-bifrost: r3 -> r4 — iter17 XFB primitive decomposition' (#70) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-r4-iter17-xfb-decomp into main ... Reviewed-on: #70	2026-05-21 12:18:23 +00:00
marfrit	83e8eca56d	mesa-panvk-bifrost: r3 -> r4 — iter17 XFB primitive decomposition ... iter17 closes the 162 winding_* CTS failures from iter15's baseline by replacing the upstream pan_nir_lower_xfb call with a panvk-specific NIR pass (panvk_per_arch(nir_lower_xfb)) that handles per-primitive decomposition for non-LIST topologies (LINE_STRIP, TRIANGLE_STRIP, TRIANGLE_FAN, and the four _WITH_ADJACENCY variants). Topology + per-instance output vertex count are threaded as new sysvals (vs.xfb_topology + vs.xfb_output_count) so the NIR pass can dispatch per-topology at runtime without compiling 7+ shader variants. dEQP-VK.transform_feedback.simple.* result (133596 cases total): iter15 baseline -> iter17 Pass: 796 958 (+162) Fail: 243 81 (-162; resume_* by-design only) NotSupported: 132551 132551 Fatal-skip: 6 6 Pass rate of runnable: 76.2% -> 91.7% (+15.5pp) 100% of the iter15 winding-fail cluster closed. The remaining 81 fails are all resume_* (pause/resume XFB, by design — we advertise transformFeedbackDraw=false). Second-model review (janet) produced 3 findings; Findings 1+2 were already fixed in the in-tree applied state (stale applied_state/ snapshot read by reviewer), Finding 3 (degenerate N underflow on N<2) addressed by gating non-LIST emission on `output_count > 0` predicate. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-21 14:07:00 +02:00
marfrit	1c8c186681	Merge pull request 'daedalus-v4l2-dkms: 79256dc -> 6ffe92b — fix kernel panic regression from #67' (#69) from claude-noether/marfrit-packages:noether/daedalus-dkms-bump-6ffe92b into main ... Reviewed-on: #69	2026-05-21 12:00:15 +00:00
claude-noether	a0be2dcc9f	daedalus-v4l2-dkms: 79256dc -> 6ffe92b — fix kernel panic from #7 ... Kernel-only bump. Fixes the hard-reboot regression introduced by the daedalus-v4l2#7 split-completion design and observed on higgs (Pi CM5) during the first mpv vaapi-copy playback of 720p H.264: device_run now removes src + dst from m2m_ctx's rdy_queue at the moment it picks them up, not at buf_done time. Without this, a parked dst_buf (waiting for libavcodec's display-order release) stayed in the rdy_queue and got re-picked by the next device_run after SRC_CONSUMED's job_finish released the scheduler — two inflight entries on the same vb2_buffer, later HAS_PIXELS calls list_del on an already-detached list_head, panic. DAEDALUS_PROTO_VERSION stays at 1 — daemon (userspace daedalus-v4l2) need NOT bump in lockstep with this DKMS update. The existing daedalus-v4l2 0.1.0+r28+g79256dc is wire-compatible with daedalus-v4l2-dkms 0.1.0+r30+g6ffe92b. Refs: * reauktion/daedalus-v4l2#8	2026-05-21 13:56:42 +02:00
marfrit	eb89f12c3e	Merge pull request 'libva-v4l2-request-fourier: bump pin to c454618 (#15 transparent resize)' (#68) from claude-noether/marfrit-packages:bump-libva-fourier-c454618-issue-15 into main ... Reviewed-on: #68	2026-05-21 11:25:39 +00:00
marfrit	ce2fff1a4f	libva-v4l2-request-fourier: bump pin to c454618 (#15 transparent resize) ... Bumps both Arch PKGBUILD and Debian build-deb.sh pins to PR #16 — codec_store_buffer + request_pool_resize transparent OUTPUT-pool grow on a mid-session resolution upshift overrun. Picks up the frame- survival path that supersedes #13's drop-and-recreate fallback. Dual-pin per feedback_marfrit_packages_dual_pin so both Arch and Debian repos see check-already-published.sh report a new version.	2026-05-21 13:24:21 +02:00
marfrit	9301894997	Merge pull request 'daedalus-v4l2{,-dkms}: f0d4186 -> 79256dc — H.264 B-frame reorder fix + menu ctrls' (#67) from claude-noether/marfrit-packages:noether/daedalus-bump-79256dc into main ... Reviewed-on: #67	2026-05-21 10:51:14 +00:00
claude-noether	f21c1ff80a	daedalus-v4l2{,-dkms}: f0d4186 -> 79256dc — H.264 B-frame reorder + menu ctrls ... Lock-step bump of both packages to daedalus-v4l2#7 + #4. PROTO_VERSION bumps 0 → 1 at the daemon ↔ kernel chardev wire: REQ_DECODE adds __u64 src_pts (the OUTPUT vb2 timestamp); RESP_FRAME adds __u32 flags (HAS_PIXELS / SRC_CONSUMED) + __u64 output_src_pts (= frame->pts on drain). Both .debs must be installed atomically or the chardev handshake rejects the version mismatch. * daedalus-v4l2: daemon's send_packet → receive_frame loop now stamps pkt->pts = req->src_pts and looks up the cookie for each drained frame via frame->pts. chardev_client emits multiple RESP_FRAME messages per REQ_DECODE when libavcodec's display- order DPB releases an earlier frame on receipt of a later bitstream — fixes the "2 1 4 3 6 5" pair-swap on H.264 streams with B-frames. * daedalus-v4l2-dkms: kernel device_run mirrors src_buf timestamp into REQ_DECODE.src_pts. Completion path splits HAS_PIXELS / SRC_CONSUMED: src is released as soon as send_packet succeeds (so the m2m scheduler moves on), dst stays parked until the matching frame is drained later. TIMESTAMP_COPY's auto src→dst pairing no longer applies once lifecycles decouple — dst is stamped explicitly from inflight->src_pts at HAS_PIXELS time. * daedalus-v4l2-dkms also carries forward the -2 multi-kernel postinst fix (#64) from the prior PKGREL. PKGREL resets to 1 on the new upstream pin. The daedalus-v4l2#4 H.264 DECODE_MODE + START_CODE menu controls (a cosmetic warning fix that PR landed alongside #7) is also subsumed — "Unable to set control(s) error_idx=2/2" no longer fires. Refs: * reauktion/daedalus-v4l2#7 * reauktion/daedalus-v4l2#4 * reauktion/daedalus-v4l2#6	2026-05-21 12:41:12 +02:00
marfrit	e15b887d8d	Merge pull request 'libva-v4l2-request-fourier: bump pin to 2860d75 (#13 bounds-check fix)' (#66) from claude-noether/marfrit-packages:bump-libva-fourier-2860d75-issue-13 into main ... Reviewed-on: #66	2026-05-21 10:38:03 +00:00
marfrit	b69db65037	libva-v4l2-request-fourier: bump pin to 2860d75 (#13 bounds-check fix) ... Bumps both the Arch PKGBUILD and the Debian build-deb.sh pins to PR #14 merge — codec_store_buffer bounds-checks for VASliceDataBufferType. Picks up the SIGSEGV fix for mpv --hwdec=vaapi-copy on resolution upshift mid-stream (issue #13). Dual-pin so check-already-published.sh detects both pool ABIs as needing a fresh build.	2026-05-21 12:19:04 +02:00
marfrit	adcc824bf7	Merge pull request 'daedalus-v4l2-dkms: postinst — autoinstall for all installed kernels (#64)' (#65) from claude-noether/marfrit-packages:fix/daedalus-dkms-multi-kernel-64 into main ... Reviewed-on: #65	2026-05-21 09:28:47 +00:00
claude-noether	7213b23861	daedalus-v4l2-dkms: postinst — autoinstall for all installed kernels (#64) ... Previously dkms autoinstall ran only against $(uname -r), so installing the package on kernel A and rebooting into separately-installed kernel B left /lib/modules/B/updates/dkms/ empty. /dev/daedalus-v4l2 absent, daedalus daemon nothing to talk to, browser/VAAPI silently falling back to software with no obvious diagnostic for the user. Now we enumerate every /lib/modules/*/build that resolves to a real directory (i.e. headers are actually installed for that kernel) and run 'dkms autoinstall -k <kver>' for each. Per-kernel verify; aggregated warning only for the kernels that didn't build. Tested locally: enumeration filters dangling /build symlinks correctly (2 kernels installed, 1 has headers → only that one is built against). Bumps PKGREL 1 → 2. Closes #64. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-21 11:07:35 +02:00
marfrit	2cd3acd680	Merge pull request 'firefox-fourier 0003: proper V4L2REQUEST type acceptance patch (closes #60)' (#63) from firefox-0003-v4l2request-proper-2026-05-21 into main ... Reviewed-on: #63	2026-05-21 05:10:27 +00:00
marfrit	22ac3c9845	firefox-fourier 0003: V4L2REQUEST type acceptance (proper patch, regenerated from real source) ... Closes #60. Resolves the malformed-patch issue from #61 (since reverted in #62) by regenerating the 0003 patch via actual application against firefox 150.0.3 Pi-OS source. Functional change vs prior 0003: walking hw_configs accepts AV_HWDEVICE_TYPE_DRM (legacy) OR integer device_type values 13/14 (AV_HWDEVICE_TYPE_V4L2REQUEST in Kwibos no-AMF / upstream-AMF trees). CreateV4L2RequestDeviceContext passes integer 13 (Kwibos value) cast to enum AVHWDeviceType for the av_hwdevice_ctx_create call. Tested: applied cleanly via patch -p1 against firefox-150.0.3 source post-Pi-OS-quilt-patches. Test build follow-up in firefox-rpios EC2 script (drops the in-source sed hack from v7-v8).	2026-05-21 06:59:20 +02:00
marfrit	3275d06728	Merge pull request 'Revert #61: malformed firefox-fourier 0003 patch' (#62) from revert-pr-61-malformed-patch into main ... Reviewed-on: #62	2026-05-21 04:33:35 +00:00
marfrit	33b91cf7dc	Revert "Merge pull request 'firefox-fourier patch #3: accept AV_HWDEVICE_TYPE_V4L2REQUEST too' (#61) from fix/firefox-v4l2request-type-accept-2026-05-21 into main" ... This reverts commit a640633ea7, reversing changes made to de3c2c6744.	2026-05-21 06:32:39 +02:00
marfrit	a640633ea7	Merge pull request 'firefox-fourier patch #3: accept AV_HWDEVICE_TYPE_V4L2REQUEST too' (#61) from fix/firefox-v4l2request-type-accept-2026-05-21 into main ... Reviewed-on: #61	2026-05-21 04:18:28 +00:00
marfrit	5f21a71770	firefox-fourier patch #3: accept AV_HWDEVICE_TYPE_V4L2REQUEST too ... Closes part of #60 (firefox-side patch update for fourier2 ffmpeg). Background: libavcodec61-fourier2 (Kwiboo v4l2-request-n7.1.3 backed) registers its hwaccels with AV_HWDEVICE_TYPE_V4L2REQUEST (the dedicated enum added in FFmpeg 7.1+), not AV_HWDEVICE_TYPE_DRM as fourier1 did. The firefox-fourier patch #3 walked hw_configs looking only for DRM and fell through to software for every codec. Patch updates: - CreateV4L2RequestDeviceContext now takes an int aDeviceType (Mozillas bundled libavutil headers may lack the V4L2REQUEST enumerator), passed through to av_hwdevice_ctx_create. - hw_configs walk accepts DRM (legacy) OR V4L2REQUEST integer value (13 on Kwibooss no-AMF tree, 14 on upstream-AMF tree). - Renamed mDRMDeviceContext to mV4L2RequestDeviceContext for accuracy. Build pkgrel will be bumped at debian-package level to +fourier2.	2026-05-21 00:09:54 +02:00
marfrit	de3c2c6744	Merge pull request 'daedalus-v4l2{,-dkms}: 462aa4b -> f0d4186 — per-ctx vb2 lock' (#58) from claude-noether/marfrit-packages:noether/daedalus-bump-f0d4186 into main ... Reviewed-on: #58	2026-05-20 19:27:39 +00:00
marfrit	e7e79e5a76	daedalus-v4l2{,-dkms}: 462aa4b -> f0d4186 — per-ctx vb2 lock ... Upstream PR #3 — kernel per-context vb2_queue lock so concurrent clients of /dev/video0 don't serialise on a device-wide mutex. Pi 5 Firefox VAAPI playback (RDD + content + GPU processes each opening the device) now works without S_FMT EBUSY collisions. Verified on higgs: YouTube playback engages daedalus at sustained ~230 fps decode through the libavcodec dlopen path, ~7× headroom over the 30fps@1080p Pi 5 Fourier target. Both packages: pkgver 0.1.0.r24.f0d4186, pkgrel reset to 1. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 21:26:16 +02:00
marfrit	130a259c69	Merge pull request 'libva-v4l2-request-fourier: c1bb444 -> 77f9236 (PR #12 / issue #11 libva side)' (#57) from claude-noether/marfrit-packages:noether/libva-bump-77f9236 into main ... Reviewed-on: #57	2026-05-20 19:18:38 +00:00
claude-noether	9580f33cb6	libva-v4l2-request-fourier: c1bb444 -> 77f9236 (PR #12 / issue #11 libva side) ... Bumps both Arch (PKGBUILD) and Debian (build-deb.sh) sides in one commit this time — following the dual-pin lesson from PR #53. 77f9236 = libva PR #12 merge: src/av1.{c,h} implements av1_set_controls mapping VAPictureParameterBufferAV1 onto struct v4l2_ctrl_av1_sequence, queued via S_EXT_CTRLS as V4L2_CID_STATELESS_AV1_SEQUENCE. The daedalus_v4l2 daemon track will consume the ctrl to synthesise an OBU_SEQUENCE_HEADER and prepend it to the slice bitstream, so libdav1d can parse the OUTPUT buffer that ffmpeg-vaapi delivers without the sequence header. Until the daemon-side OBU synth lands (issue #11 operator track), the SEQUENCE ctrl is just sitting in the request unused. Harmless on the RK3588 vpu981 hardware path (vpu981 parses OBU bytes directly, ignores the ctrl payload). pkgver: r382.c1bb444 -> r386.77f9236 (commit count 382 -> 386, two new upstream commits: 9fa18f2 av1 + 77f9236 merge). pkgrel: 1 (fresh pkgver, no rebuild-only iteration). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 21:17:54 +02:00
marfrit	eab66cfab8	Merge pull request 'build.yml: convert ffmpeg+mpv-debian install-deps to apt-get (closes #55)' (#56) from fix/debian-runner-deps-2026-05-20 into main ... Reviewed-on: #56	2026-05-20 19:13:50 +00:00
marfrit	d2cecbcd05	build.yml: convert ffmpeg+mpv-debian install-deps to apt-get ... Closes #55. PR #47 routed ffmpeg-v4l2-request-debian and mpv-fourier-debian to runs-on: debian-aarch64 (bohr), but their install-deps steps still called pacman -Syu. That is a latent break that would surface on the next pkgver bump (currently silent-skipped by check-already-published.sh since pool versions match the staged PKGVER). This patch follows PR #50's pattern (daedalus-v4l2{,-dkms}-debian): - Replace retry pacman -Syu ... with retry apt-get install ... - Translate Arch package names to Debian (base-devel -> build-essential, pkgconf -> pkg-config, libdrm -> libdrm-dev, x264 -> libx264-dev, etc.). - For mpv: drop the "configure [marfrit] repo + pre-install ffmpeg-v4l2-request-fourier" step entirely. Under apt, stock libavcodec-dev / libavformat-dev / libavutil-dev provide trixie-ABI headers matching what mpv-fourier's binary will see at runtime; the daemon dlopens the fourier libs if installed but doesn't link against them at build time. Validated upstream: equivalent debian build-deps installed cleanly in PRs #44 (libva) and #50 (daedalus).	2026-05-20 21:09:50 +02:00
marfrit	2028eccc3c	Merge pull request 'daedalus-v4l2{,-dkms}: 3dd0eb0 -> 462aa4b — kernel ctrl-binding fix' (#54) from claude-noether/marfrit-packages:noether/daedalus-bump-462aa4b into main ... Reviewed-on: #54	2026-05-20 18:45:09 +00:00
marfrit	70c8c2b417	daedalus-v4l2{,-dkms}: 3dd0eb0 -> 462aa4b — kernel ctrl-binding fix ... Upstream PR #2 landed the one-line kernel fix that was the missing half of issue libva-v4l2-request-fourier#8: device_run now calls v4l2_ctrl_request_setup() before reading ctrl->p_cur, so the daedalus_h264_meta the daemon receives reflects the in-flight media_request's bound H.264 stateless control values instead of stale/default ones. Pairs with libva-v4l2-request-fourier 1.0.0+r382+gc1bb444 (max_num_ ref_frames fallback + Fix 4 instrumentation that exposed the control-binding gap in the first place). Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against H.264 sources now produces actual decoded content (per-frame fnv1a hashes differ, zero MB-decode errors) instead of the constant 0x6a6a05c5 "best-effort give-up" hash and cascading decode warnings. Both packages: pkgver 0.1.0.r22.462aa4b, pkgrel reset to 1. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:38:32 +02:00
marfrit	793187ff9e	Merge pull request 'libva-v4l2-request-fourier (deb): catch build-deb.sh up to c1bb444 (follow-up to #52)' (#53) from claude-noether/marfrit-packages:noether/libva-deb-bump-c1bb444 into main ... Reviewed-on: #53	2026-05-20 18:30:24 +00:00
claude-noether	42bf6b1633	libva-v4l2-request-fourier (deb): 9898331 -> c1bb444 (parallel to PR #52) ... PR #52 bumped only arch/libva-v4l2-request-fourier/PKGBUILD; the sibling debian/libva-v4l2-request-fourier/build-deb.sh has its own parallel UPSTREAM_COMMIT + PKGVER + PKGREL pin that I missed. Result: the libva-v4l2-request-fourier-debian CI job ran post-merge, check-already-published.sh saw the .deb-side filename derived from build-deb.sh (libva-v4l2-request-fourier_1.0.0+r380+g9898331-1_arm64.deb) was already in the pool, returned skip=1, and the job short-circuited. trixie repo Packages still advertises r380 instead of r382. This bump catches build-deb.sh up to the same pin (c1bb444) so the next merge triggers the build + reprepro publish path. No code change beyond the three pinned variables + the comment block. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:29:10 +02:00
marfrit	40719efc43	Merge pull request 'libva-v4l2-request-fourier: 9898331 -> c1bb444 (PR #9 / issue #8 fix)' (#52) from claude-noether/marfrit-packages:noether/libva-bump-c1bb444 into main ... Reviewed-on: #52	2026-05-20 18:23:42 +00:00
claude-noether	e540384f50	libva-v4l2-request-fourier: 9898331 -> c1bb444 (PR #9 / issue #8 fix) ... Bumps the libva backend pin to include marfrit/libva-v4l2-request-fourier PR #9 — h264_set_controls fix for the bitstream-vs-session value drift that breaks the daedalus_v4l2 strict-consumer path (issue #8): * max_num_ref_frames fallback when VAAPI client left it 0 (count valid DPB entries, then per-profile spec minimum) * one-line request_log at h264_set_controls entry dumping raw VAAPI bitfields for disambiguating remaining PPS-flag-zero portion of #8 The PR explicitly defers the deeper "profile_idc / level_idc from bitstream" portion of #8 — VAAPI's VAPictureParameterBufferH264 omits both fields, so a real fix needs SPS-NAL parsing or daedalus wire-protocol pass-through. Not in this bump. pkgver: 1.0.0.r380.9898331 -> 1.0.0.r382.c1bb444 (commit count 380->382) pkgrel: 1 (fresh pkgver, no rebuild-only iteration) Verified on higgs (Debian 13 trixie, gcc 14.2.0, libva 2.22.0): clean meson build, vainfo enumerates all 8 codec profiles, multi-device probe still wires rkvdec / rpi-hevc-dec / daedalus_v4l2. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:21:46 +02:00
marfrit	9ca97374c8	Merge pull request 'mesa-panvk-bifrost: iter13 — implement VK_EXT_transform_feedback for Bifrost' (#51) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-iter13 into main ... Reviewed-on: #51	2026-05-20 17:33:05 +00:00
marfrit	902e855d92	mesa-panvk-bifrost: iter13 — implement VK_EXT_transform_feedback for Bifrost ... iter12 hit a wall: Brave's ANGLE-Vulkan path requires GLES3, which requires VK_EXT_transform_feedback, which PanVk-Bifrost did not implement. This iter implements that extension, unlocking the full ANGLE-Vulkan-on-Bifrost stack. The implementation follows Panfrost-Gallium's well-validated XFB lowering (nir_io_add_intrinsic_xfb_info + pan_nir_lower_xfb) wired into the PanVk shader pipeline after nir_lower_io. Adds 4 XFB buffer address sysvals plus per-draw num_vertices to the graphics sysval struct. Buffer state is tracked on the cmd buffer; per-draw sysval upload populates either the bound buffer's GPU address or PAN_SHADER_OOB_ADDRESS (memory-sink) so XFB-capable pipelines used outside Begin/End survive without GPU fault — the Panfrost-Gallium idiom from gallium/drivers/panfrost/ pan_cmdstream.c:1350. Verified on PineTab2 (Mali-G52 r1 MC1, RK3566): - /tmp/panvk-iter13/probe_xfb: 3 vertices captured byte-exact - /tmp/panvk-iter13/probe_xfb_nodraw: XFB pipeline used without Bind/ Begin/End survives — DEVICE_LOST regression closed - Brave 148 with --use-angle=vulkan: WebGL 2.0 (OpenGL ES 3.0) creates cleanly, renderer reports "ANGLE (ARM, Vulkan 1.2.335 (Mali-G52 r1 MC1), panvk)" - chrome://gpu graphics feature status: Canvas/Compositing/OpenGL/ Rasterization/WebGL/WebGL2/WebGPU/Video Decode all hardware accelerated Phase docs: - ~/src/panvk-bifrost/phase4_iter13_close.md (build green) - ~/src/panvk-bifrost/phase5_iter13_close.md (review fixes applied) - ~/src/panvk-bifrost/phase6_iter13_close.md (Brave integration green) pkgver bumped 26.0.6.r2 -> 26.0.6.r3; iter13 patch applied via unified-diff (the 328-line change scope is past sed-of-individual- lines territory). Sanity checks in prepare() verify the patch landed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 19:13:05 +02:00
marfrit	64269d69ee	Merge pull request 'ci: convert daedalus-v4l2{,-dkms}-debian install steps to apt-get' (#50) from claude-noether/marfrit-packages:noether/ci-fourier-debian-apt into main ... Reviewed-on: #50	2026-05-20 17:06:21 +00:00
marfrit	e976c88016	ci: convert daedalus-v4l2{,-dkms}-debian install steps to apt-get ... PR #47 moved the daedalus-v4l2-debian + daedalus-v4l2-dkms-debian jobs from runs-on: arch-aarch64 to runs-on: debian-aarch64, but left the install-deps steps using `pacman -Syu` — which doesn't exist on the Debian runner. Both jobs were latent-broken; the break only surfaces once a daedalus pkgver actually changes (the rebuild guard skipped them in runs #133-134 since nothing about daedalus moved between PR #47 and PR #48). PR #49 bumped both daedalus packages to 0.1.0+r20+g3dd0eb0 (the DAEMON-PPS H.264 SPS/PPS NAL synth landing) — so run #135's daedalus-debian + daedalus-dkms-debian jobs actually executed and hit the broken pacman step. Result: instant failure on `pacman -Syu`. Fix: replace the pacman invocations with apt-get equivalents. For daedalus-v4l2-debian, drop the [marfrit] ffmpeg-v4l2-request- fourier preinstall — Debian's stock libavcodec-dev / libavformat- dev / libavutil-dev provide matching headers (both trixie ffmpeg and the daedalus daemon's runtime dlopen target are libavcodec 61.x), and the daemon never link-binds against libav (Option γ — dlopen at runtime), so any header set with the right struct definitions works. Verified end-to-end on higgs (Debian trixie aarch64, equivalent to bohr): clone the source tarball, run build-deb.sh, produces daedalus-v4l2_0.1.0+r20+g3dd0eb0-1_arm64.deb cleanly (10/10 ninja steps, daedalus_v4l2_daemon binary linked). NOTE: ffmpeg-v4l2-request-debian (line ~907) and mpv-fourier- debian (line ~1048) have the same pacman-on-Debian bug from PR #47 but are still skipped because their pkgvers haven't moved. Not fixing those in this PR to keep the change focused on unblocking DAEMON-PPS verification — they'll need the same treatment the next time they bump. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 19:03:36 +02:00
marfrit	29cc145d44	Merge pull request 'daedalus-v4l2{,-dkms}: 481279c -> 3dd0eb0 (DAEMON-PPS close)' (#49) from claude-noether/marfrit-packages:noether/daedalus-bump-3dd0eb0 into main ... Reviewed-on: #49	2026-05-20 16:54:11 +00:00
marfrit	b16a3f1a77	daedalus-v4l2{,-dkms}: 481279c -> 3dd0eb0 (DAEMON-PPS close) ... Upstream PR #1 landed daemon-side synthesis of H.264 SPS/PPS NAL units from the V4L2 stateless control structs. This bumps the package pin so both the userspace daemon and the kernel module pick up the change in lockstep (wire protocol grew a new DAEDALUS_REQ_FLAG_H264_META bit + struct daedalus_h264_meta — kernel and daemon MUST match). Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against H.264 sources will actually decode through the daedalus daemon instead of failing with "non-existing PPS 0 referenced". Both arch + debian packages: pkgver 0.1.0.r20.3dd0eb0 (count from git rev-list), pkgrel reset to 1 (new upstream pin). VP9 / AV1 paths unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 18:53:04 +02:00
marfrit	c2018413aa	Merge pull request 'libva-v4l2-request-fourier: c332d34 -> 9898331 (LIBVA-2 close)' (#48) from claude-noether/marfrit-packages:noether/libva-bump-9898331 into main ... Reviewed-on: #48	2026-05-20 15:09:08 +00:00
marfrit	243e05ca5e	libva-v4l2-request-fourier: c332d34 -> 9898331 (LIBVA-2 close) ... Follow-up to libva PR #7 (merged as 9898331). Without that commit, H.264/VP9/AV1 profiles never got advertised on Pi 5 mixed deploys (rpi-hevc-dec primary + daedalus_v4l2 alt) because the profile- enumeration probe in any_fd_supports_output_format only walked rkvdec / hantro / rpi-hevc-dec / vpu981 fds. ffmpeg vaapi -i h264_test.mp4 on higgs bailed with "No support for codec h264 profile 578" before the LIBVA-1 per-codec dispatch could even fire. 9898331 extends the fds[] from 5 to 6 with video_fd_daedalus as the 6th slot (HAVE_DAEDALUS_V4L2-gated, -1 fallback otherwise). Effect on higgs once this lands: vainfo lists VP9Profile0 + AV1Profile0 + H264* alongside HEVCMain, and ffmpeg -hwaccel vaapi -i h264_test.mp4 routes through the daedalus daemon (via 'd' kind in request_switch_device_for_profile). Both packages: pkgver 1.0.0.r380.9898331 (count from rev-list), pkgrel reset to 1 (new upstream pin). Backward-compatible on RK3399/3588 — the new fd slot is gated by HAVE_DAEDALUS_V4L2 *and* video_fd_daedalus >= 0, both false in those deployments. Companion to the prior LIBVA-{1,ABI} bumps that landed in marfrit- packages PRs #43, #44. Together they close the Pi 5 stack: boot -> modules-load.d loads daedalus_v4l2 -> daedalus-v4l2.service starts daemon -> libva opens both decoders -> ffmpeg -hwaccel vaapi enumerates all codecs from both -> routes per-codec. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 17:08:07 +02:00
marfrit	a29fe71666	build.yml: route 4 fourier-debian jobs to debian-aarch64 (bohr) (#47) ... Closes task #134 work. PR #44 showed the cross-distro ABI hazard for `libva-v4l2-request-fourier-debian`: building on Arch (libva 2.23) produced `__vaDriverInit_1_23`, which trixies libva 2.22 runtime cant bind. Same hazard applies to other fourier-debian jobs that link against debian-native libs. **Moved from runs-on: arch-aarch64 → debian-aarch64:** - ffmpeg-v4l2-request-debian - mpv-fourier-debian - daedalus-v4l2-debian - daedalus-v4l2-dkms-debian **Left alone (arch=all, no native compile against debian libs):** - lmcp-debian - claude-his-debian Depends on PR #46 (label vs name fix) being merged so `debian-aarch64` actually routes to bohr. Reviewed-on: #47	2026-05-20 14:39:43 +00:00
marfrit	b0ffd4d74f	Merge pull request 'build.yml: runs-on debian-aarch64 (label, not runner name)' (#46) from fix/debian-runner-label-2026-05-20 into main ... Reviewed-on: #46	2026-05-20 13:54:01 +00:00
marfrit	ab60acd9f4	build.yml: runs-on debian-aarch64 (label, not runner name) ... 5feab57 set runs-on to actrunner-debian-aarch64-bohr, which is the display name of the bohr runner, not a label. Gitea Actions matches runs-on against labels — the actual labels on bohr are debian-trixie, aarch64, debian-aarch64. Using the runner-name as runs-on leaves the job unrouted (no matching runner).	2026-05-20 15:52:40 +02:00
claude-noether	6a417fcc9d	libva-v4l2-request-fourier-debian: route to debian-aarch64-bohr runner (#45) ... Two follow-ups to PR #44 (which landed the libva-dev ABI pin): - `051da5e` switch runs-on from arch-aarch64 → debian-aarch64-bohr - `5feab57` fix runner label: actrunner-debian-aarch64-bohr (label name mismatch in 051da5e) **Squash on merge** to keep main history clean. Co-authored-by: Markus Fritsche <mfritsche@reauktion.de> Reviewed-on: #45 Co-authored-by: Claude (noether) <claude@reauktion.de> Co-committed-by: Claude (noether) <claude@reauktion.de>	2026-05-20 13:08:30 +00:00
marfrit	1c77b05f68	Merge pull request 'libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI' (#44) from claude-noether/marfrit-packages:noether/libva-trixie-abi-pin into main ... Reviewed-on: #44	2026-05-20 12:59:40 +00:00
marfrit	051da5e8dc	libva-v4l2-request-fourier-debian: switch to debian-aarch64-bohr runner ... Per @marfrit on PR #44 review: a native Debian trixie aarch64 runner (debian-aarch64-bohr) is available — use it instead of the sysroot hack from the previous commit. The sysroot approach worked but was a workaround for not having the right runner. Native trixie runner is much cleaner: - libva-dev installs via apt-get directly from trixie's archive (2.22.0-3) — pkg-config returns trixie headers, driver compiles in __vaDriverInit_1_22 naturally. - No need to symlink libva.so.2 -> libva.so or rewrite .pc prefixes. - No bsdtar/ar/dpkg-deb juggling on an Arch runner that doesn't natively have dpkg. Changes from PR v1: - .gitea/workflows/build.yml: libva-v4l2-request-fourier-debian runs-on: debian-aarch64-bohr (was arch-aarch64). Build-deps installed via apt-get instead of pacman -Syu. - build-deb.sh: drop the sysroot download / pkgconfig rewrite / symlink block. Keep the post-build ABI sanity check (nm -D | grep __vaDriverInit_1_22) — same defensive role as before, with an updated error message that points to the expected runner. - debian/.../changelog: -2 entry rewritten to describe the runner move instead of the sysroot. Tested approach on boltzmann (aarch64): meson build against trixie sysroot produces __vaDriverInit_1_22 (proves the source compiles correctly with VA-API 1.22 headers). Native runner build will follow the same path, just without the explicit sysroot setup. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 14:58:37 +02:00
marfrit	a1ff6de652	libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI ... The libva-v4l2-request-fourier .deb shipped with the wrong VA-API symbol export because the CI runner is Arch (libva 2.23 = VA-API 1.23) while the install target is Debian trixie (libva 2.22 = VA-API 1.22). At compile time, <va/va.h>'s VA_MAJOR/VA_MINOR macros are baked into the driver's __vaDriverInit_<MAJOR>_<MINOR> symbol name. trixie's libva runtime looks up __vaDriverInit_1_22, our driver only exported __vaDriverInit_1_23, so dlsym() returned NULL and libva fell back to its sentinel error "has no function __vaDriverInit_1_0". Result: ffmpeg -hwaccel vaapi fails on startup, vainfo fails the same way, on every Pi 5 / CM5 that installed the package. The driver itself doesn't link libva.so (no NEEDED entry — confirmed via readelf on higgs), so the only thing that matters is the symbol NAME the compiler bakes in. Fix is small: in build-deb.sh, download trixie's libva-dev / libva2 / libva-drm2 .deb from deb.debian.org, extract to a sysroot, rewrite the .pc prefixes, and set PKG_CONFIG_PATH so pkg-config returns trixie headers regardless of what the runner has installed. The link step still resolves -lva against the sysroot's libva.so.2, but the resulting .so has no NEEDED entry for it. Added a hard sanity check at the end of build-deb.sh: fail the build if the produced .so doesn't export __vaDriverInit_1_22. This makes future ABI-skew failures loud at CI time instead of silent install- then-refuse-to-load on the target. Tested on boltzmann (aarch64): sysroot build produces a .so exporting __vaDriverInit_1_22 (verified via nm -D). Source unchanged from c332d34; only the build env differs. pkgver/upstream unchanged. PKGREL bumped 1 -> 2 (rebuild against pinned trixie libva-dev) so apt picks up the new .deb on higgs. This is the LIBVA-2 unblocker — the runtime-libva-bind failure was masking whether the LIBVA-1 per-codec dispatch actually works on higgs. Once -2 lands on packages.reauktion.de, apt upgrade on higgs and the daedalus daemon log + rpi-hevc-dec dispatch can be validated end-to-end. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 14:31:40 +02:00