marfrit
a7892bfabc
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.
vb2 dma_resv release-fence — RFC patch series
A 3-patch RFC series that adds an opt-in dma_resv exclusive-fence
API to videobuf2, with hantro and rockchip-rga as the first two
drivers to opt in. Drafted as part of the
fourier campaign — see the
top-level KWIN_PIVOT.md
for the discovery thread.
Files
0000-cover-letter.patch
0001-media-videobuf2-add-dma_resv-release-fence-helper.patch
0002-media-hantro-attach-dma_resv-release-fence-at-buf_queue.patch
0003-media-rockchip-rga-attach-dma_resv-release-fence-at-buf_queue.patch
What this fixes
vb2 producers historically don't propagate buffer-state-done into
the dmabuf's dma_resv exclusive fence. Userspace consumers that
import V4L2-produced dmabufs and try to do implicit synchronization
the spec-clean way (poll(POLLIN) on the dmabuf fd, or
DMA_BUF_IOCTL_EXPORT_SYNC_FILE for a sync_file) get either zero
fences or a stub fence from dma_fence_get_stub(). This is correct
by accident for the common case (clients call DQBUF before
importing) but represents a contract gap.
The opt-in API in patch 1 lets a driver populate a real fence at
QBUF time and have it signalled by vb2_buffer_done. Patches 2 and 3
demonstrate the call shape on hantro and rga (one line each in
their respective buf_queue callbacks).
Status
Patches drafted but not yet applied / compile-tested / runtime-
tested. They're written against linux-next master as of
2026-04-28 (sparse-checked-out at /tmp/hantro-src during the
chromium-fourier campaign on ohm). Pre-flight before sending:
- Compile —
make drivers/media/common/videobuf2/videobuf2-core.o drivers/media/platform/verisilicon/hantro_v4l2.o drivers/media/platform/rockchip/rga/rga-buf.oagainst the kernel tree the patches will land on. Fix any drift in declarations or line numbers. - Boot test on ohm — install the patched kernel, verify hantro
and rga still queue/dequeue buffers correctly (mpv
--vo=drmsmoke test, gstreamer rga pipeline smoke test). - Validate the fence semantics — install patched kernel, also uninstall the kwin-fourier package (so KWin's watchDmaBuf is active again), play 1080p30 H.264 in chromium-fourier under KDE Plasma 6.6.4 Wayland: should plays through end-to-end without the watchDmaBuf bypass, because the fence wait now waits on a real fence that signals when hantro completes the buffer.
- Capture timings —
dma_buf_export_sync_fileround-trip latency before and after, on the same hardware. The patch should not regress; ideally the fence-add path is fast enough that compositor latency improves slightly (the wait now fires on real producer completion instead of a stub-resolved poll).
If 3 passes, the RFC has end-to-end validation backing the submission. Send to linux-media:
git format-patch --cover-letter --to=linux-media@vger.kernel.org \
--cc='Hans Verkuil <hverkuil@xs4all.nl>' \
--cc='Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>' \
--cc='Mauro Carvalho Chehab <mchehab@kernel.org>' \
--cc='dri-devel@lists.freedesktop.org' \
-3 HEAD
Open questions for upstream review
(Listed in the cover letter; copying here for convenience.)
- Opt-in vs. auto-on: should every CAPTURE queue auto-attach fences, or stay opt-in per-driver? Auto-on is more correct but forces every driver to be audited; opt-in is incremental and safer.
- Signal point:
vb2_buffer_doneis the latest moment the producer-write is guaranteed-complete. For drivers with async post-processing stages (image-processor pipelines) the producer fence might want to fire at an earlier point. Out of scope for this RFC; revisit when an actual driver complains. - DMA_RESV_USAGE_WRITE vs. older
dma_resv_set_excl_fence: matches dma-buf documentation for "this device produced a write." Sanity check welcome.
License
Patches are GPL-2.0-only matching the kernel source. The cover letter is informational.