# Track F (V4L2_MEMORY_DMABUF on OUTPUT) — research + verdict

Authored 2026-05-06 in response to operator request after iter7 close. The candidate had been carried for five iterations as "high-risk architectural" without concrete research. This document records the research outcome and the final disposition.

## Prior art (every production V4L2 stateless H.264 consumer)

| Consumer | OUTPUT (bitstream input) | CAPTURE (decoded frames) | Reference |
|---|---|---|---|
| FFmpeg kwiboo (`libavcodec/v4l2_request.c`) | `V4L2_MEMORY_MMAP` | `V4L2_MEMORY_MMAP` + `VIDIOC_EXPBUF` | The empirical authority for the campaign per `feedback_ffmpeg_v4l2_request_is_authority.md` |
| GStreamer `v4l2codecs` (`gstv4l2decoder.c`) | `V4L2_MEMORY_MMAP` | `V4L2_MEMORY_MMAP` + DMABUF export | All REQBUFS/CREATE_BUFS calls pass `.memory = V4L2_MEMORY_MMAP` |
| Chromium V4L2 VDA (`v4l2_video_decode_accelerator.cc`) | `V4L2_MEMORY_MMAP` | `V4L2_MEMORY_DMABUF` import (when in IMPORT mode for compositor) | OUTPUT stays MMAP regardless of mode |
| Mainline hantro driver (`drivers/media/platform/verisilicon/hantro_drv.c`) | advertises `VB2_MMAP \| VB2_DMABUF` | advertises `VB2_MMAP \| VB2_DMABUF` | Kernel exposes both as capabilities |
| Rockchip rkvdec staging driver (`drivers/staging/media/rkvdec/rkvdec.c`) | advertises `VB2_MMAP \| VB2_DMABUF` | advertises `VB2_MMAP \| VB2_DMABUF` | Same pattern as hantro |

**Takeaway:** every real consumer uses MMAP on OUTPUT. The kernel exposes DMABUF as a capability but **no production code path exercises it.** A campaign Track F port would be the first exerciser of OUTPUT-DMABUF on hantro for H.264.

## Rockchip platform coverage (driver split per SoC)

| SoC | H.264 decode driver | Notes |
|---|---|---|
| RK3399 (PineBook Pro, RockPro64) | `rkvdec` (staging) | hantro VPU on this SoC has H.264 explicitly disabled; H.264 routes through rkvdec |
| RK3568 | hantro vpu (`rockchip,rk3568-vpu`) | This is what the campaign's hantro fork targets via DT |
| **RK3566 (PineTab2 — actual silicon)** | should be `rkvdec2`/`vdpu346` | **No mainline driver yet.** Christian Hewitt patch series LKML 2025/12/26/206, not merged as of campaign closure date |
| RK3588 | `rkvdec2` (merged Feb 2026) | Hantro on this SoC handles encode only |

**Important campaign-documentation finding**: the campaign's docs have referred to PineTab2 as RK3568 throughout. PineTab2 is actually RK3566. The hantro `rk3568-vpu` DT compatible apparently works because the silicon is close enough — but the campaign's iter1..iter7 evidence is on RK3566 silicon running the rk3568 driver path. This has not been a problem, but it's a load-bearing detail to record.

## Kernel-side OUTPUT-DMABUF state for hantro / rkvdec

Both drivers declare `VB2_DMABUF` in `io_modes` for the OUTPUT queue. The vb2 import path (`vb2_dma_contig_memops` with `attach_dmabuf`/`map_dmabuf`) would handle the DMA attachment.

Wrinkle: the hantro OUTPUT queue is configured with:
```c
src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES | DMA_ATTR_NO_KERNEL_MAPPING;
```

`DMA_ATTR_NO_KERNEL_MAPPING` applies to the allocator path (MMAP), not the importer path (DMABUF). DMABUF import is not blocked by this flag.

No kernel mailing list discussion of "hantro OUTPUT-DMABUF for H.264" was found — neither working examples nor breakage reports. This is honestly an untested path.

## Cost/benefit synthesis

### What Track F would buy us
- **Original justification (cap_pool race)**: closed organically by iter5/iter6/iter7. No residual motivation.
- **Theoretical zero-copy from an upstream compressed-bitstream producer**: doesn't apply. Firefox demuxes from network/disk; mpv demuxes from file. Neither allocates the compressed bitstream via dma-heap and exports it as dma-buf. The canonical DMABUF zero-copy story is for raw video frames on the CAPTURE side (already DMABUF-exported via `VIDIOC_EXPBUF`), not compressed bitstream on the OUTPUT side.

### Cost
- New alloc path (dma-heap or dmabuf-heap allocator in userspace).
- New QBUF/DQBUF lifecycle with fd passing instead of buffer-index-only.
- New kernel path through `vb2_dma_contig` importer — first exerciser on hantro for H.264.
- Complete replacement of `request_pool.c` MMAP-based slot management.

### Risk
- Moderate to high. Untested kernel path. No precedent to reference.

## Verdict: DROP

Track F is **dropped from the campaign roadmap**.

The candidate was created in iter2 as a structural fix for the cap_pool race. That race has been closed by other means (iter5 sweep + iter6 REINIT discipline + iter7 OUTPUT-pool teardown). The candidate's original purpose no longer exists. The alternative benefit case (zero-copy from upstream producer) has no realistic source in the campaign's pipeline. Every production V4L2 stateless H.264 consumer uses MMAP on OUTPUT. The kernel-side DMABUF support is advertised but untested.

**Drop.** Move on.

## What would reopen this

A future pipeline stage where compressed bitstream arrives from another hardware component (DMA engine, network offload, hardware demux) that allocates and exports the bitstream as a dma-buf fd before libva sees it. That is not a scenario on any current or chartered Rockchip SoC embedded target.

If the campaign ever expands to hardware where this is the case (TI TDA4VM-class with hardware demux, secure-content paths on Qualcomm-class, etc.), reconsider. Until then: removed from the roadmap.

## Operator action

Update `phase0_findings_iter6.md` and `phase0_findings_iter7.md` candidate F entries to reflect dropped status; this document is the canonical reference. No iter8 work on this candidate.

The PineTab2-is-RK3566-not-RK3568 finding is recorded above and will be picked up by future docs as needed; not a campaign correctness issue, just nomenclature accuracy.