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>
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.
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>
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>
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>
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>
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>
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>
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>
Claude (noether)
test0r