fresnel-fourier/phase4_iter12_plan.md

# Iteration 12 — Phase 4 plan + Phase 6 implementation

Major pivot at iter12 Phase 0 close: user signaled "RFC v2 is already prepared and should be included in fresnel's running kernel." This changes iter12's vehicle from "OUTPUT byte dump (α-16)" to **"integrate vb2_dma_resv RFC v2 into linux-fresnel-fourier 7.0-2 and reboot fresnel."**

## Why this matters for Bug 4 + Bug 5

Per `reference_dmabuf_resv_blocker.md`:
> RK3399 hantro/rkvdec CAPTURE → libva readback returns all-zero pages until vb2_dma_resv kernel patches land.

The bugs we've been chasing (Bug 4 H.264 partial-fill, Bug 5 HEVC all-zero) are not in libva's wire-payload. iter9 + iter11 exhausted the wire-byte search space with 10 confirmed-inert field changes (constraint_set_flags, POC sentinel, reference_ts magnitude, sps_max_num_reorder_pics, IRAP/IDR flags, num_entry_point_offsets, …). The kernel decodes correctly; the readback via libva's cached-mmap returns stale / zero / partial-write data.

RFC v2 attaches a `dma_resv` exclusive WRITE fence to V4L2-produced dmabufs at `device_run` time. Userspace consumers that implicit-sync via `poll(POLLIN)` or `DMA_BUF_IOCTL_EXPORT_SYNC_FILE` will:
- See a real signalled fence after decode completes (not the stub).
- Get cache-coherent buffer access guaranteed by the fence semantics.

Whether this fixes our libva → ffmpeg-vaapi-hwdownload pixel readback path specifically depends on whether ffmpeg-vaapi's read uses the fence. If it does (or if installing the patch incidentally fixes the cache-coherency mechanism it touches), Bugs 4 + 5 may close.

## Patches

Located at `boltzmann:~/v2-patch-work/v2-out/`:

| Patch | Subject | Size |
|---|---|---|
| 0000 | cover letter | 7,063 bytes |
| 0001 | media: videobuf2: add opt-in dma_resv producer fence helper | 13,089 bytes |
| 0002 | media: hantro: attach dma_resv release fence at device_run | 4,136 bytes |
| 0003 | media: rockchip-rga: attach dma_resv release fence at … | 4,469 bytes |

Cover-letter excerpt:
> v2 of the vb2 dma_resv producer-fence series. Two substantive changes addressing v1 review:
> 1. Attach point moves from buf_queue to m2m device_run. v1 attached at buf_queue, which violates the dma_fence finite-time contract (Nicolas Dufresne, [linux-rockchip][2]): a fence published when userspace QBUFs is observable to consumers immediately, but the OUTPUT-side driver may be starved indefinitely if userspace never queues bitstream chunks. By moving the attach to device_run, we publish only after the m2m core has committed to running the job.

## Integration plan

1. Copy the 3 patches into `~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/linux-fresnel-fourier/` on boltzmann as `0004-*.patch`, `0005-*.patch`, `0006-*.patch`. ✓ done.
2. Update PKGBUILD source=() array to include them. ✓ done.
3. Bump `pkgrel` from 1 to 2. ✓ done.
4. Run `makepkg -fs --noconfirm` on boltzmann (native, 8 cores, no distcc per kernel-agent policy). ⏳ in progress.
5. Stage sddm auto-login as `mfritsche` (`/etc/sddm.conf.d/20-autologin.conf`) on fresnel before reboot. ✓ done.
6. scp `linux-fresnel-fourier-7.0-2-aarch64.pkg.tar.zst` from boltzmann to fresnel.
7. `sudo pacman -U` on fresnel.
8. Reboot fresnel.
9. Verify new kernel running (`uname -a` reports `7.0.0-fresnel-fourier` with newer build timestamp).
10. Run 5-codec sweep + γ instrumentation to check whether Bug 4 + Bug 5 hashes change.

## Risks

- **R-1**: RFC v2 patch doesn't apply cleanly to mmind v7.0 base. Probability: low — same base as v1 which built clean (existing 7.0-1 package). Mitigation: if patch fails, fix conflicts manually on boltzmann; rebuild.
- **R-2**: Kernel boots but new module signatures break. Probability: very low — patches are media-driver-only; no symbol exports the rest of the kernel depends on. Mitigation: keep 7.0-1 entry in extlinux menu (PKGBUILD's hook already creates a parallel boot option per the PKGBUILD comment "User picks at u-boot menu. Reverting = boot the linux-eos-arm entry.").
- **R-3**: Kernel boots but libva-vaapi still produces broken HEVC/H.264 output. **The most likely outcome** — RFC v2's fence machinery may not engage with libva's specific cached-mmap readback (ffmpeg-vaapi-hwdownload). Bug 4 + Bug 5 stay open; iter12 close as PARTIAL with kernel-substrate upgraded.
- **R-4**: Kernel boots and FIXES Bug 4 + Bug 5. Bigger campaign milestone. Possible if libva's path implicitly benefits from the fence-publishing.
- **R-5**: Some other regression (panfrost, sound, USB) post-reboot. Probability: very low (patches are media-only). Mitigation: rollback via extlinux 7.0-1 option.

## Phase 5 review concerns

Reviewer should confirm:
- The 3 patches modify only `drivers/media/common/videobuf2/`, `drivers/media/platform/verisilicon/hantro/`, `drivers/media/platform/rockchip/rga/`. No accidental wide changes.
- PKGBUILD source array correctness (all 3 patches listed; SKIP'd checksums for all entries).
- `extlinux-add` hook still files a parallel boot entry so 7.0-1 remains as fallback.

This is a quick review since the user has already prepared the patches and authorized the kernel work flow.

## Phase 7 verification

After reboot:
1. `uname -a` shows new build timestamp.
2. `dmesg | grep -i "vb2\|dma_resv\|hantro\|rkvdec"` — any new RFC v2 trace messages OR no errors.
3. 5-codec sweep:
   - H.264 → was `71ac099b…`. Compare.
   - HEVC → was `06b2c5a0…`. Compare.
   - VP9 → was `4f1565e8…`. Must hold.
   - MPEG-2 → was `19eefbf4…`. Must hold.
   - VP8 → was `bcc57ed5…`. Compare (may change).
4. γ dump verifies what's in CAPTURE buffers post-DQBUF.

iter12 PASS = libva hashes for Bug 4 + Bug 5 codecs change toward kdirect values + 4 working anchors hold.
iter12 PARTIAL = kernel upgraded cleanly, no regression, but Bug 4 + 5 hashes unchanged.

## Iter12 close shape

Both PASS and PARTIAL are valuable — the kernel substrate moves to vb2_dma_resv-enabled, which the campaign has wanted since iter1 closed `reference_dmabuf_resv_blocker.md`. Whatever the libva pixel result, the kernel substrate upgrade is achieved.