fresnel-fourier/phase8_iteration22_close.md

Iteration 22 — Phase 8 (close)

Closes 2026-05-14. iter22 = kernel printk in v4l2_ctrl_request_clone tracing each handler_new_ref step. FULL close. iter21's mid-conclusion is overturned: the request-clone-hdl is COMPLETE for libva — all 22 controls cloned with err=0.

Method

linux-fresnel-fourier 7.0-6 added per-step pr_info to v4l2_ctrl_request_clone:

pr_info("iter22_clone_start: new_hdl=%p from=%p\n", hdl, from);
list_for_each_entry(ref, &from->ctrl_refs, node) {
    ...
    err = handler_new_ref(hdl, ctrl, &new_ref, false, true);
    pr_info("iter22_clone_step: id=0x%x err=%d hdl_error=%d new_ref=%p\n",
            ctrl->id, err, hdl->error, new_ref);
    ...
}
pr_info("iter22_clone_end: hdl=%p err=%d\n", hdl, err);

Built ~2 min via ccache. Deployed via scp + pacman -U + reboot.

Results

libva HEVC (11 clones — one per request_fd binding):

Every clone-step logs err=0 hdl_error=0 new_ref=valid_ptr. Each clone has 22 controls successfully added, ending with iter22_clone_end err=0. Full ID list per clone:

0x990001, 0x990a67, 0x990a6b, 0x990b00, 0x990b67, 0x990b68,
0xa40001, 0xa40900, 0xa40901, 0xa40902, 0xa40903, 0xa40904, 0xa40907,
0xa40a2c, 0xa40a2d,
0xa40a90, 0xa40a91, 0xa40a92, 0xa40a93, 0xa40a94, 0xa40a95, 0xa40a96

Note: H264_PRED_WEIGHTS (0xa40905) and H264_SLICE_PARAMS (0xa40906) are NOT in the source main_hdl (these are not registered in rkvdec_h264_ctrls on this kernel — rkvdec doesn't expose them). All 7 HEVC stateless decode controls ARE present.

kdirect HEVC (13 clones): identical pattern, identical ID set, all err=0.

What this overturns from iter21

iter21 concluded the clone-hdl was missing 6 HEVC controls for libva. That was wrong. The clone-hdl actually has all 22 controls. The iter21_setup_ref printk's iteration was filtering 8 of them out via the early-return check:

if (ref->req_done || (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
    continue;

For libva, only 14 refs reach the printk. For kdirect, 21 refs reach it. 8 vs 1 difference in skip count.

What this implies

Two of the 8 skipped controls are clearly READ_ONLY: codec class roots 0x990001 and 0xa40001 (V4L2_CTRL_TYPE_CTRL_CLASS). That accounts for 2 of 8 in both libva and kdirect.

For libva, 6 additional HEVC controls (PPS, SLICE_PARAMS, SCALING_MATRIX, DECODE_PARAMS, DECODE_MODE, START_CODE) get skipped. For kdirect, only DECODE_MODE + START_CODE get skipped (the 2 with p_req_valid=0 that aren't staged this frame).

Wait — kdirect shows DECODE_MODE + START_CODE in the setup_ref printk with p_req_valid=0. So they're NOT skipped by the continue check. So kdirect's 21 displayed = 22 cloned - 1 (only one CLASS root being printed?). Hmm, mismatch.

Actually the iter21 setup_ref for kdirect showed 21 lines visible — 20 entries +1 setup header. Let me re-examine. The kdirect dump had 21 ctrl_refs lines (excluding setup: line). 22 clone - 21 setup_ref = 1 skipped. Possibly only one class root present in kdirect's clone-hdl somehow.

So the actual difference is: libva skips 8, kdirect skips 1. The 7 EXTRA skips for libva are: 6 HEVC controls (PPS, SLICE, SCALING, DECODE_PARAMS, DECODE_MODE, START_CODE) + 1 mystery.

Mechanism status (post-iter22)

#	Mechanism	Status
1	request_fd mismatch	DISPROVED
2	REINIT clears	DISPROVED iter19
3	Stack-locals stale	DISPROVED iter18
4	ctrl_hdl mismatch	REFRAMED iter20
5	error_idx silent failure	DISPROVED iter18
6	req->p_new staging incomplete	iter21 → 22 OVERTURNED (clone IS complete)
7	Clone-hdl missing controls	DISPROVED iter22 (clone has all 22)
8	NEW iter22: 6 of 7 HEVC controls get skipped in v4l2_ctrl_request_setup loop for libva but not kdirect	leading hypothesis

iter23 candidate

Add printk inside the v4l2_ctrl_request_setup loop before the continue check, logging req_done, flags, ncontrols, cluster[0]->id:

pr_info("iter23_loop: id=0x%x req_done=%d flags=0x%x ncontrols=%d cluster0_id=0x%x\n",
        ctrl->id, ref->req_done, ctrl->flags,
        master->ncontrols,
        master->cluster[0] ? master->cluster[0]->id : 0);
if (ref->req_done || (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
    continue;

Two possible findings:

• req_done already true for the 6 HEVC controls → an earlier iteration (HEVC_SPS) clustered them and set req_done. Means main_hdl's HEVC_SPS has master->cluster containing PPS+SLICE+SCALING+DECODE_PARAMS+DECODE_MODE+START_CODE on libva's path.
• flags has READ_ONLY → the controls have READ_ONLY set, which is wrong for stateless decode controls.

ncontrols and cluster0_id reveal cluster membership directly: if ncontrols > 1 for HEVC_SPS, it's been clustered with siblings.

Substrate state at iter22 close

• Backend SHA on fresnel: c1d4bb53… (iter15 stable, unchanged).
• Fork tip e109306 (α-24 reverted) — unchanged.
• Kernel linux-fresnel-fourier 7.0-6 with iter17 + iter20 + iter21 + iter22 printks.
• 5-codec anchors: unchanged.

Iter23 build kicked off

linux-fresnel-fourier 7.0-7 building on boltzmann (PID 1643224, log /tmp/iter23-kbuild.log). Expected ~2 min via ccache.

Lesson

iter21's mid-conclusion was based on the wrong printk position — the iter21_setup_ref printk was inside v4l2_ctrl_request_setup's loop but AFTER the early-continue checks, missing controls that get skipped. iter22's clone-trace showed the clone IS complete; the staging FAILS via the setup-loop SKIP path, not the clone path.

The empirical pattern is now: libva's per-frame request gets through clone correctly; gets through S_EXT_CTRLS correctly (stages all 5 controls with p_req_valid=1 — at least for SPS, definitely 1); but at setup-loop time, 6 of the 7 HEVC controls get a continue that bypasses req_to_new. SPS alone reaches req_to_new → try_or_set_cluster → commits to p_cur → rkvdec_run reads ctx->ctrl_hdl[SPS]->p_cur which is non-zero?

Actually — wait, iter20 said sps[0..16] was zero for libva. If SPS is the only one that reaches req_to_new + try_or_set_cluster, then SPS's content SHOULD be correct, but iter20 said it's zero. So SPS itself ALSO has a problem in the commit path.

So we have:

• 6 of 7 HEVC controls: never reach req_to_new (skipped in setup loop).
• 1 of 7 (SPS): reaches req_to_new but resulting p_cur content is zero anyway.

These are TWO separate bugs (or one bug with two symptoms). iter23 will reveal the skip mechanism; another iter (or test) may need to address the SPS-commit-content issue.