fresnel-fourier/phase0_findings_iter17.md

Iteration 17 — Phase 0 + Phase 6 (kernel-side investigation)

Opens 2026-05-14 after iter16's confirmation that Bug 4 + Bug 5 + Bug 6 are kernel-side. Per feedback_libva_byte_correct_kernel_bug.md, libva-side hypothesis space is exhausted. Productive direction is kernel investigation via kernel-agent workflow.

Locked research question (iter17)

"At the rkvdec_hevc_run() entry on RK3399, are the struct values pointed to by run->sps, run->pps, run->slices_params[0], run->decode_params byte-equal between libva-triggered and kdirect-triggered HEVC decodes? If yes, the divergence is inside rkvdec's per-call hardware setup (assemble_hw_, config_registers, IRQ handler). If no, libva is somehow passing different struct contents despite ioctls being byte-equal."*

Approach

Kernel printk diagnostic at rkvdec_hevc_run entry (after rkvdec_hevc_run_preamble that populates run from V4L2 control state):

pr_info("rkvdec_hevc_run: sps_id=%u dpb_buf=%u reorder=%u"
        " w=%u h=%u bd_l=%u bd_c=%u chroma=%u"
        " num_short_st=%u num_long_lt=%u"
        " slices=%u nal_unit_type=%u slice_type=%u"
        " decode_flags=0x%x\n", ...);

Build linux-fresnel-fourier 7.0-3 with this printk, deploy, reboot, run libva-HEVC + kdirect-HEVC each, capture dmesg, diff.

Substrate state at iter17 open

• Fork tip 111f8ba on noether + fresnel + gitea (α-20 reverted).
• Backend SHA 80e65c5a… on fresnel.
• Kernel 7.0-2 currently. iter17 will deploy 7.0-3 with the diagnostic printk.
• Pkgrel bumped to 3 in PKGBUILD on boltzmann.

Why this is the right next investigation

iter11–iter16 cumulative empirical findings:

• libva submits byte-identical V4L2 controls (every rkvdec-read field).
• libva submits byte-identical OUTPUT bitstream (HEVC frame 1: 96890 bytes match input exactly; VP8: 300614 bytes match input exactly minus header).
• libva ioctl sequence has been brought to structural near-parity with kdirect (S_FMT CAPTURE, DMA_BUF_IOCTL_SYNC, IRAP/IDR flags, POC strip, timestamp counter).

At the V4L2 ioctl layer, libva == kdirect for every observable byte. The kernel must therefore see different state internally — either through some non-ioctl path (vb2 allocator difference, buffer alignment, request_fd ordering) OR within rkvdec's per-call processing (assemble_hw_*, config_registers).

The printk at rkvdec_hevc_run entry shows the kernel's view of run->* struct contents. If those are byte-equal between libva and kdirect, the bug is in assemble/config_registers/IRQ. If they differ, libva is somehow leaking state through a path we haven't traced.

Phase 5 review acknowledgment

This is a diagnostic-only kernel patch (single printk, no behavior change). No Phase 5 review needed for the patch itself; the methodology is direct empirical comparison.

If the printk reveals a real bug, the actual fix will require Phase 5 architectural review per CLAUDE.md "reviews never skippable."

Phase 7 plan

After 7.0-3 deploys:

1. Reboot fresnel (sddm autologin kicks in).
2. sudo dmesg -C to clear.
3. Run libva HEVC; capture dmesg; expect 3 frames worth of printk lines.
4. sudo dmesg -C again.
5. Run kdirect HEVC; capture dmesg.
6. Diff the two dmesg outputs.

What outcomes mean

• Identical: kernel sees the same run->* data from both backends. Bug 4/5/6 is in rkvdec's assemble/config_registers/HW. Next step: instrument those.
• Different: libva somehow gets different struct contents into rkvdec despite identical ioctls. Investigate.