Commit Graph

1 Commits

Author SHA1 Message Date
claude-noether 358801be06 Track F (V4L2_MEMORY_DMABUF on OUTPUT): research + DROP verdict
Sonnet architect researched the candidate that's been carried for
five iterations. Key findings:

- FFmpeg kwiboo, GStreamer v4l2codecs, Chromium V4L2 VDA: all use
  V4L2_MEMORY_MMAP on OUTPUT. Zero production consumers use DMABUF.
- Mainline hantro + Rockchip rkvdec drivers advertise VB2_DMABUF
  capability but no consumer exercises it. Untested kernel path
  for hantro H.264 OUTPUT-DMABUF.
- Original cap_pool-race justification: closed organically by
  iter5+iter6+iter7. No residual motivation.
- Zero-copy-from-upstream-producer alternative benefit: no
  realistic producer in the campaign's pipeline (Firefox/mpv
  don't allocate compressed bitstream via dma-heap).

Bonus campaign-docs finding: PineTab2 is RK3566 (rkvdec2/vdpu346
target — no mainline driver yet, Christian Hewitt patch series
LKML 2025/12/26/206 not merged), not RK3568 as the campaign
docs have stated. The hantro rk3568-vpu DT compatible works
because the silicon is close enough; not a correctness issue,
just nomenclature accuracy.

Verdict: DROP. Track F off the iter8+ roadmap. Reopen criterion
documented for hardware-pipeline scenarios that are not on any
currently-chartered Rockchip SoC.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-06 11:19:00 +00:00