initial seed: retrofit campaign lineage from local working trees

panvk-bifrost campaigns (r1..r4 Vulkan compositor + r5.video1 Vulkan
video decode) shipped before this repo existed; the deliverable
patches live in marfrit-packages, but the reasoning chain, phase docs,
and source-state evidence lived only in local working trees on the
development host.

This retrofit imports:
- mesa-panvk-bifrost/   — r1..r4 era phase docs (iter1..iter18)
                          (libmali stub blobs at iter18/blob/ excluded
                          — 109MB of RE artifacts replaced with a README
                          pointer)
- mesa-panvk-bifrost-video/ — sibling campaign phase docs + probe
- evidence/             — frozen .tgz source snapshots at each milestone
                          (basis for the 0005 patch diff generation)

Future iterations should branch off here from day one, so each iter is
a commit rather than a snapshot. See [[feedback-session-local-process-pins]]
for the process drift this retrofit closes.

Total: 1.9 MB across 124 files.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

mesa-panvk-bifrost-video/phase4_progress.md

@@ -0,0 +1,50 @@
+# Phase 4 progress — panvk-bifrost-video Commits 1-6 landed; 7b residual
+
+State at 2026-05-21 20:40 UTC. All evidence in `phase0_evidence/`.
+
+## What's working end-to-end
+
+1. **Three required Vulkan video extensions advertised**: `VK_KHR_video_queue`, `VK_KHR_video_decode_queue`, `VK_KHR_video_decode_h264` (probe_vkvideo PASS 5/5).
+2. **Video decode queue family** advertised at Vulkan idx 1 (PAN_ARCH<9), with `VK_QUEUE_VIDEO_DECODE_BIT_KHR | VK_QUEUE_TRANSFER_BIT` and `videoCodecOperations = VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR`.
+3. **Video session create/destroy**: opens real V4L2 fds to `/dev/video1` + `/dev/media0`, negotiates multi-planar `H264_SLICE` OUTPUT + `NV12` CAPTURE formats, REQBUFS both queues with `V4L2_MEMORY_DMABUF`, allocates 18 request_fds via `MEDIA_IOC_REQUEST_ALLOC`, sets device-level `DECODE_MODE_FRAME_BASED + START_CODE_ANNEX_B` controls, STREAMON.
+4. **Per-physical-device capability + format entrypoints**: `panvk_GetPhysicalDeviceVideoCapabilitiesKHR` (max 1920×1088, 16 DPB slots, level 4.2), `panvk_GetPhysicalDeviceVideoFormatPropertiesKHR` (NV12).
+5. **`Cmd*Video*` entrypoints dispatch reaches our code**: Begin/End/Control/Decode are called per the spec for vk-video-samples simple-test. The first frame's params parse correctly: sps_id=0, pps_id=0, IdrPicFlag=0, 0 refs, src bitstream 6273 bytes.
+6. **Std → V4L2 H.264 bridge compiled in**: `panvk_v4l2_h264_std_to_ctrl_sps`, `_pps`, `_scaling_matrix`, `_default_flat_scaling_matrix`, `_build_decode_params` (460 LoC, agent-authored, field-by-field map cited to V4L2 kernel docs).
+7. **14-step V4L2 ioctl dance compiled in**: `panvk_v4l2_submit_h264_decode` does `S_EXT_CTRLS` (request_fd-bound) → `QBUF OUTPUT` → `QBUF CAPTURE` → `MEDIA_REQUEST_IOC_QUEUE` → `poll(POLLPRI, 200ms)` → `DQBUF OUTPUT/CAPTURE`. Per Phase 2 D7.
+
+## What's deferred — Commit 7b
+
+The Cmd*Video* entrypoints currently log entry and discard their inputs. To actually decode, they need to:
+
+1. **Access `cmdbuf->video.{vs,params}` fields**. These fields exist on JM `panvk_cmd_buffer` (added in this iter). Access requires the per-arch header, which an arch-agnostic source file can't reach.
+   **Fix**: relocate the four Cmd*Video* entrypoints to `jm/panvk_vX_video_decode_cmd.c` so they compile only for PAN_ARCH<9 and have native access to the JM cmdbuf struct.
+
+2. **Translate parameters per frame**. The Std→V4L2 bridge is ready; call site needs:
+   - `vk_video_find_h264_dec_std_sps(params, pStdPictureInfo->seq_parameter_set_id)` — lookup active SPS from session params
+   - `vk_video_find_h264_dec_std_pps(params, sps_id, pic_parameter_set_id)`
+   - `panvk_v4l2_h264_std_to_ctrl_sps/pps()`
+   - `panvk_v4l2_h264_default_flat_scaling_matrix()` (Phase 1; real scaling matrix is later)
+   - `panvk_v4l2_h264_build_decode_params(vs, h264_pi, pps, dst_slot, refs, ts, &c_dec)`
+
+3. **Resolve VkBuffer→dmabuf and VkImage→dmabuf**. Open work — panvk's buffer/image management doesn't expose a direct BO accessor for arbitrary VkBuffer handles. Two candidate paths:
+   - **DMABUF path**: walk VkBuffer→bound VkDeviceMemory→`panvk_device_memory.bo`→`pan_kmod_bo_export()` (pattern at `panvk_device_memory.c:400`). Requires extending `panvk_buffer` to track its bound memory, OR using `vk_buffer`'s implicit binding.
+   - **MMAP path**: REQBUFS with `V4L2_MEMORY_MMAP` instead of DMABUF, `mmap()` the kernel-allocated buffers, copy bitstream in / decoded frame out at QBUF/DQBUF time. Slower (CPU copies) but completely sidesteps panvk's BO integration. **Probably the right Phase 1 minimum.**
+
+4. **Call `panvk_v4l2_submit_h264_decode()`**. The function exists, takes the four control structs + src/dst dma_buf fds + timestamp, runs the 14-step dance synchronously.
+
+5. **Update `vs->dpb[dst_slot]`** with the output timestamp so the next frame's `build_decode_params` finds the reference correctly.
+
+## Snapshot for resume
+
+- Source tarball: `phase0_evidence/commits_1-6_source_snapshot_2026-05-21.tgz` (47KB, 10 files)
+- Test output: `phase0_evidence/vk_video_samples_commit4-6_2026-05-21.txt` (entrypoint dispatch confirmed)
+- Probe baseline: `phase0_evidence/probe_vkvideo_commit1_PASS_2026-05-21.txt` (5/5 PASS, regression check)
+- Build host: ohm at `/home/mfritsche/mesa-build/mesa-26.0.6/`
+- Live patched lib: `/home/mfritsche/panvk-patched-libs/libvulkan_panfrost.so`
+- ICD JSON: `/tmp/iter17_icd.json` (points at patched lib)
+
+## Per dev_process
+
+Phase 4 stays open (Commit 7b residual). Phase 5 (janet review), Phase 6 (real decode validation), Phase 7 (mpv-fourier consumer proof), Phase 8 (package r1 of `mesa-panvk-bifrost-video`) are all gated on 7b.
+
+— claude-noether, 2026-05-21