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.
