fresnel-fourier/phase7_iter17_findings.md

Iteration 17 — Phase 7 (kernel-side diagnostic finding)

Captured 2026-05-14 on fresnel running linux-fresnel-fourier 7.0-3 (kernel module reloaded; vmlinux unchanged so uname -v still shows 7.0-2 timestamp, but rkvdec module is the iter17 build).

Method

Added one pr_info() at the entry of rkvdec_hevc_run (RK3399 variant in rkvdec-hevc.c) dumping key state values from run->sps, run->slices_params[0], run->decode_params — the structs that rkvdec_hevc_run_preamble populates via v4l2_ctrl_find(&ctx->ctrl_hdl, ID)->p_cur.p.

Result — definitive

Captured 28 lines of dmesg across libva + kdirect HEVC decode runs. Representative sample:

libva HEVC (run 1 of 13 — all 13 identical):

rkvdec_hevc_run: sps_id=0 dpb_buf=0 reorder=0
                 w=0 h=0 bd_l=0 bd_c=0 chroma=0
                 num_short_st=0 num_long_lt=0
                 slices=1 nal_unit_type=0 slice_type=0
                 decode_flags=0x0

kdirect HEVC (run 1 of 15):

rkvdec_hevc_run: sps_id=0 dpb_buf=4 reorder=2
                 w=1280 h=720 bd_l=0 bd_c=0 chroma=1
                 num_short_st=0 num_long_lt=0
                 slices=1 nal_unit_type=20 slice_type=2
                 decode_flags=0x3

The kernel sees completely different control struct contents. For libva: all-zero SPS dimensions, zero nal_unit_type, zero decode_flags. For kdirect: correct width=1280, height=720, IRAP|IDR flags, slice_type=I.

What this overturns

iter11–iter15 had established that libva's S_EXT_CTRLS wire-byte payloads were byte-equal to kdirect's for every field rkvdec reads. That was correct at the strace observer level — userspace passed the same bytes to the kernel.

But at the rkvdec-read level (after MEDIA_REQUEST_IOC_QUEUE should have copied request controls to ctx->ctrl_hdl->p_cur), libva's values are zero while kdirect's are correct.

The wire-byte search exhaustion was an illusion. The controls are submitted correctly but lost somewhere between S_EXT_CTRLS and rkvdec_hevc_run_preamble.

Possible mechanisms

1. request_fd mismatch: libva's S_EXT_CTRLS uses one request_fd, libva's QBUF/IOC_QUEUE uses another. Controls stash in request A; ctx->ctrl_hdl never sees A's values.

2. REINIT clears controls before QUEUE: libva's media_request_reinit may run on the request between S_EXT_CTRLS and IOC_QUEUE for the NEXT frame. iter6 lifecycle: REINIT runs AFTER wait_completion of the previous decode — should be safe, but worth double-checking.

3. Compound-control copy timing: kernel's v4l2_s_ext_ctrls() for which=V4L2_CTRL_WHICH_REQUEST_VAL may defer the payload copy until IOC_QUEUE. If libva's userspace pointer (a stack local in h265_set_controls) is gone by then, kernel reads garbage/zeros.

4. ctrl_hdl mismatch: libva's S_EXT_CTRLS goes to one ctrl_hdl (e.g., the file-handle-private), but rkvdec_hevc_run_preamble reads from another (the m2m-context's). Per V4L2 m2m design these should be the same, but could be misregistered.

5. error_idx silently fails: kernel returns 0 from S_EXT_CTRLS but actually skipped the controls due to a flag/validation failure. error_idx in the controls struct would reveal this.

For kdirect: same kernel, same /dev/video1, same m2m-ctx-class — but it works. So mechanisms 3 and 4 are unlikely (they'd break kdirect too).

Mechanisms 1, 2, 5 are libva-specific and worth direct testing.

kdirect storage shape

V4L2RequestControlsHEVC in ffmpeg-v4l2request:

typedef struct V4L2RequestControlsHEVC {
    V4L2RequestPictureContext pic;
    struct v4l2_ctrl_hevc_sps sps;
    struct v4l2_ctrl_hevc_pps pps;
    ...
};
V4L2RequestControlsHEVC *controls = h->cur_frame->hwaccel_picture_private;

Heap-allocated (av_mallocz_array via hwaccel_picture_private). Pointer valid for the AVFrame's full lifecycle — many seconds.

Libva's h265_set_controls:

struct v4l2_ctrl_hevc_sps sps;     // stack local
struct v4l2_ctrl_hevc_pps pps;     // stack local
struct v4l2_ctrl_hevc_decode_params decode_params;  // stack local
struct v4l2_ctrl_hevc_scaling_matrix scaling_matrix;  // stack local
struct v4l2_ctrl_hevc_slice_params *slice_params_array = NULL;  // heap (calloc)
...
controls[n++] = (struct v4l2_ext_control){.id = SPS, .ptr = &sps, .size = sizeof(sps)};
...
rc = v4l2_set_controls(...);

Stack locals — valid only for h265_set_controls's duration. After that function returns and EndPicture's other code runs (QBUF, IOC_QUEUE), the stack may be reused.

If the kernel defers copy_from_user() for compound controls until MEDIA_REQUEST_IOC_QUEUE (which is after h265_set_controls returns), the userspace pointer is stale.

The V4L2 kernel spec says S_EXT_CTRLS for compound controls copies immediately — but a kernel bug or version-specific deferred-copy could fit.

Test hypothesis — heap-allocate libva's HEVC controls

If mechanism 3 (deferred copy) is correct, moving libva's HEVC controls from stack to heap (a calloc()'d struct, owned by surface_object, freed at DestroyContext) would fix the issue without any other change.

This is iter18 α-21. ~20-30 LOC change in h265.c.

Phase 7 conclusion

iter17's kernel printk produced a definitive empirical finding: the kernel reads zero control values for libva HEVC despite libva submitting non-zero bytes via S_EXT_CTRLS. The bug is at the userspace-pointer-lifetime / kernel-copy-timing layer, NOT in libva's ioctl content.

This is the strongest narrowing in the campaign since iter5b-β.

iter18 candidate (α-21)

Heap-allocate libva's HEVC control structs so the pointer remains valid until MEDIA_REQUEST_IOC_QUEUE actually runs. If α-21 fixes Bug 5, apply same pattern to H.264 controls and VP8 controls (both currently use stack locals in their *_set_controls functions).

If α-21 still doesn't fix Bug 5, the bug is in mechanism 1, 2, or 5 — requires further kernel printk.

Substrate state at iter17 P7 close

• Fork tip 111f8ba (libva backend, no changes this iter).
• Kernel linux-fresnel-fourier 7.0-3 with diagnostic printk in rkvdec_hevc_run. NOT a shipping kernel — diagnostic only. Should be reverted (printk removed, rebuild as 7.0-4) once iter18 work completes OR replaced with the actual fix instead.
• Backend SHA on fresnel: c1d4bb53….