iter1 phase 2: hypothesis 3 ruled out by EXPBUF lseek probe

Probe `/tmp/expbuf_probe.c` (snapshot at probes/expbuf_probe.c) opens
/dev/video1, sets OUTPUT format H264_SLICE 1920x1088, REQBUFS 4 capture
buffers, EXPBUF on plane 0 of buffer 0, lseek(fd, 0, SEEK_END).

On ohm (kernel besser-7.0, hantro-vpu / rk3568-vpu-dec):
  CAPTURE: NV12 1920x1088 num_planes=1 sizeimage=3655712
  EXPBUF fd lseek(SEEK_END) = 3657728  (page-rounded from 3655712)

Kernel exports the dma_buf at full sizeimage; offset 2,088,960
(plane 1 base in ffmpeg's drm-frame-descriptor) is well inside.
Hantro is innocent.

Side observation: sizeimage = 3,655,712 > naive NV12's 3,133,440.
The 522,272-byte excess is trailing padding (likely Rockchip
per-frame MV / context metadata) past the UV plane. Y and UV layout
fit cleanly within [0, 3,133,440), exactly where mpv/ffmpeg expect.

Remaining hypothesis space: H1 (panfrost EGL non-zero plane offset),
H2 (KWin wl_dmabuf import), H4 (kwin-fourier residual, low conf).

Next probe queued: H2 source-read of KWin 6.6.4 wl_dmabuf import
path. ~30 min, no hardware needed. If that turns up nothing,
write the EGL importer harness for H1.

Posted to dmabuf-modifier-triage#1 comment 255.

phase2_iter1_findings.md

@@ -77,7 +77,9 @@ So the green frame is **not caused by mpv or ffmpeg's descriptor construction**.
 
 2. **KWin's wl_dmabuf import logic deduplicates the dup'd fds incorrectly.** If KWin sees two fds and detects (via `dma_buf_id` or kcmp(2)) that they're the same backing object, but then mishandles the per-plane offsets, this'd produce green. Testable: read KWin source `src/wayland/linuxdmabufv1clientbuffer.cpp` and compositor backend's EGL import path.
 
-3. **hantro kernel driver exports a `dma_buf` with `size` < full allocation.** If hantro caps the exported fd's mappable size to just the Y plane (2,088,960 bytes), offset 2,088,960 is past EOF — read fails silently, returns zeros. Testable: `ssh ohm "fcntl(F_GETSIZE) on EXPBUF fd"` or just `lseek(fd, 0, SEEK_END)` in a small probe.
+3. ~~**hantro kernel driver exports a `dma_buf` with `size` < full allocation.**~~ **RULED OUT 2026-05-08** by `/tmp/expbuf_probe.c` on ohm. Driver `hantro-vpu` on `rk3568-vpu-dec` reports `CAPTURE: NV12 1920x1088 num_planes=1 sizeimage=3655712`; `VIDIOC_EXPBUF` yields fd whose `lseek(fd, 0, SEEK_END) = 3,657,728` (page-rounded up from 3,655,712). Offset 2,088,960 (plane 1 base) is firmly inside the exported size. Kernel is innocent.
+
+   Side observation worth recording: `sizeimage = 3,655,712` is bigger than naïve NV12's 1920×1088×1.5 = 3,133,440. The 522,272-byte excess sits **past** the UV plane (Y at [0, 2,088,960), UV at [2,088,960, 3,133,440), trailing padding at [3,133,440, 3,655,712)). On Rockchip codecs that tail commonly holds per-frame motion-vector / decoder-context data. Confirms ffmpeg's hardcoded `planes[1].offset = pitch*height = 2,088,960` is correct.
 
 4. **kwin-fourier 0001 still has effect we missed.** Even though we ruled out kwin-fourier as a compositor-replacement A/B, that test was on an earlier kernel/Mesa combo. Worth verifying the test environment is fully reset.
 
@@ -93,6 +95,7 @@ d. **Update `marfrit/dmabuf-modifier-triage#1`** with this revised analysis. The
 
 ## Status
 
-- iter1 phase 2 ongoing. Pivot from "fix is in mpv" to "real layer is unclear, need more diagnostics."
+- iter1 phase 2 closed 2026-05-08. Hypotheses 3 (hantro size cap) and ad-hoc 5 (offset-mismatch from sizeimage surprise) both ruled out via `/tmp/expbuf_probe.c` runtime measurement on ohm. Real layer narrowed to hypothesis 1 (panfrost EGL_dma_buf_import for non-zero offset) and hypothesis 2 (KWin wl_dmabuf import). Hypothesis 4 still latent.
 - Acceptance criterion (`screenshots/frame10_expected.png`) is unchanged.
-- Delivery vehicle (`mpv-fourier-1:0.41.0-8`) is still the right shipping path **if** the fix turns out to be a defensive workaround in mpv. Otherwise the patch lands in ffmpeg-v4l2-request-fourier (unlikely per this analysis), KWin, kernel hantro, or a Mesa-panfrost user-mode driver patch.
+- Delivery vehicle (`mpv-fourier-1:0.41.0-8`) is still the right shipping path **if** the fix turns out to be a defensive workaround in mpv. With kernel + ffmpeg + mpv all exonerated by source-read + runtime probe, the most likely landing layers are now Mesa-panfrost (`vulkan-panfrost` package — already in marfrit) or KWin (`kwin-fourier` package — already in marfrit).
+- Next probe: hypothesis 2 source-read of KWin (cheaper, ~30 min, no hardware) before hypothesis 1 EGL importer harness (~1-2h C code).