Iteration 1 close. Boolean-correctness criterion met for vainfo +
mpv vaapi-copy + Firefox 150 in live Plasma session. mpv vaapi
(DMA-BUF) engages and decodes correctly but stutters due to a
DMA-BUF lifecycle race — deferred to iteration 2.
Four load-bearing functional commits on the fork:
9de1be3 — slice-header bit-parser populates DECODE_PARAMS bit-size
fields hantro G1 reads into MMIO registers
d41a4b9 — always submit SCALING_MATRIX + populate pps num_ref_idx
37c0e72 — re-set OUTPUT format on resolution change (mpv probe-pattern)
ac891a0 — honor VA_EXPORT_SURFACE_SEPARATE_LAYERS in vaExportSurfaceHandle
Lessons distilled to memory:
feedback_read_consumer_source_first (NEW)
feedback_one_consumer_success_is_not_validation
feedback_kernel_source_audit_for_uapi_contract (Sonnet Phase 5)
feedback_stdout_is_data_too (NEW)
feedback_no_premature_closure
Predecessor claims either reframed or invalidated:
- 'vainfo + mpv probes work end-to-end' was true at libva engagement
layer, wrong at kernel-decode layer until 9de1be3
- 'chromium-fourier 149 = libva-multi-planar working' was wrong about
mechanism; chromium-fourier uses chromium-internal V4L2 backend,
not libva. The 83 pp browser-CPU finding from fourier_attribution
cell A stands; the path attribution does not.
- 'patch 0011 sentinel test reliably detects decode failure' had a
cache-coherency bug fixed in a047926.
Open questions carried to iteration 2: DMA-BUF EXPBUF refcount
lifecycle (load-bearing), WSI pitch alignment for non-64-aligned
widths, multi-resolution kernel-state corruption, plus six items
from Sonnet's Phase 5 review.
Iteration 2 opens with these as Phase 0 substrate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
