3-patch kernel RFC drafted as part of the fourier campaign. Targets the linux-media mailing list. Index: fourier.

The architectural correction that makes the kwin-fourier wait premise ("the wait will signal correctly") actually true.

vb2 currently does not propagate V4L2 producer state into the dmabuf ''dma_resv'' exclusive fence. That means a downstream consumer (e.g. the KWin compositor polling a dmabuf for completion) cannot rely on the fence to indicate "decode finished, frame ready". Without this fix, the compositor either spins on stub fences (the bug kwin-fourier 0001 identified) or has to do the wait itself the hard way (which 0002 does as a workaround).

1. vb2 helper API for ''vb2_buffer_attach_release_fence()''
2. hantro opt-in
3. rockchip-rga opt-in

All kernel APIs verified against ''include/linux/dma-{fence,resv}.h''. Patches are drafted, regenerated via ''git format-patch'' in the shape linux-media expects.

• Target list: linux-media
• Recipe + CC list: ''upstream-submissions/vb2-dma-resv/lkml-submission-notes.md'' in ''gitea/marfrit-packages''
• Source path: ''kernel/vb2-dma-resv-rfc/'' in the same repo

• kwin-fourier 0002 does the dmabuf-fd poll dance as a workaround at the compositor level.
• vb2-dma-resv RFC fixes it at the producer level so the workaround stops being necessary.
• Both are shippable independently — different upstreams, different review cadences. The kwin patch is useful even on kernels that never get the RFC; the RFC is useful even on compositors that never take the kwin patch.