Re-baselined libva-v4l2-request decode path with kernel-side
observability (ftrace v4l2/vb2/dma_fence + dmesg + dynamic_debug)
and visual disambiguator (mpv --vo=gpu in operator's live Plasma
session).
Findings:
1. Kernel reports successful CAPTURE buffer write every frame:
ftrace vb2_buf_done shows bytesused=3655712 (full NV12 1920x1088
+ hantro tile padding). dmesg completely silent — no
hantro/vpu/decode/error/warn messages.
2. Visual disambiguator: mpv --hwdec=vaapi-copy --vo=gpu shows a
solid GREEN frame; --hwdec=vaapi --vo=gpu shows solid BLUE.
Neither shows the sentinel mid-beige (NV12 Y=0xab,UV=0xab would
render cream). Both colors are consistent with the kernel
writing all-zero NV12 (Y=0,UV=0 → green via BT.709 limited; same
buffer GL-imported as DMA-BUF with different colorspace → blue).
3. Patch 0011 sentinel test has a cache-coherency bug: writes
0xab via cached surface_object->destination_map[0] mmap, never
invalidates cache before readback. So the readback always
shows the stale sentinel even when kernel DMA-overwrote it
with zeros. vaapi-copy and Mesa DMA-BUF GL import correctly
invalidate cache and see the real (zero) contents.
This corrects the previous Phase 0 verdicts twice in one day:
- Original commit f15ba8b ("the 2026-04-26 picture holds") was
wrong: clean contract trace, never checked pixel content.
- Revised commit e892cea ("kernel produces no decoded pixel
output, sentinel survives") was half right: kernel does write,
writes zeros, and the sentinel test was reading stale cache.
- Now: kernel writes ALL ZEROS to the CAPTURE buffer. Hantro is
silently failing the bitstream parse or some control validation.
This is consistent with patch 0011's own commit message hypothesis:
"All zeros → kernel did write 0x00s (overwriting our sentinel),
and the apparent 'no picture' output is the kernel-side decode
actually producing zeros (e.g. parser rejected the bitstream)."
That hypothesis was right; we just couldn't confirm it via the
sentinel test (cache bug) and went down the wrong rabbit hole.
Phase 6 direction sharpens substantially. Bug isn't "we can't
engage hantro" — it's "hantro engages but its parser produces
zeros." Bisect the control submission: VIDIOC_G_EXT_CTRLS
readback to verify writes stick, diff against FFmpeg's
v4l2_request_h264.c (proven working on hantro), verify SPS
completeness, resolve patch 0008's slice_header bit_size open
question, dyndbg the hantro module, etc. Phase 1 boolean-
correctness criterion needs a working pixel-content check before
lock; fix patch 0011's cache sync first.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit
365764fffb