marfrit/libva-multiplanar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

iter9 phase 0: lock cap_pool/REQBUFS/REINIT cascade as the question

Browse Source 
Campaign reopen — iter8's "campaign-closing" status was contingent on
"mpv --hwdec=vaapi smooth", which doesn't hold against fresh-install
interactive testing. iter9 single-track scope:

- Bug #1 (libva-v4l2-request-fourier#1) only
- mpv H.264 fresh-login through ≥30s of decode without any of: cap_pool
  double-init, REQBUFS EBUSY, REINIT bad-fd, OUTPUT ENOMEM
- Phase 0 will source-read cap_pool + request_pool + iter6 REINIT,
  build a vo=null reproduction harness, prepare bisect against iter5
  baseline, and a libva-direct C probe for minimal repro

Bug #2 (presentation green) is dmabuf-modifier-triage's job — peer
campaign opened 2026-05-08 at ~/src/dmabuf-modifier-triage/. README
cross-link now points at it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (noether)
2026-05-08 14:01:47 +00:00
parent 16f95235b9
commit c331519507
2 changed files with 78 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -1
View File
@@ -58,7 +58,7 @@ The iter8 close (`65969da3`) was packaged as `libva-v4l2-request-fourier-1.0.0.r
1. **libva cap_pool / REQBUFS / iter6-REINIT lifecycle cascade** — filed at [marfrit/libva-v4l2-request-fourier#1](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/1). Under `mpv --hwdec=vaapi` interactive playback, `cap_pool_init` runs twice for slots 0..23 (probe-context + decode-context, no teardown between), `VIDIOC_REQBUFS` returns EBUSY (queue still STREAMON'd), iter6's per-OUTPUT-slot REINIT (commit `a09c03c`) chokes on a Bad fd, OUTPUT queue (`type=9`) hits ENOMEM after a few REQBUFS retries, decode aborts with `Failed to create surface: 2 (resource allocation failed)`. The Phase-5-sonnet-C4 caveat from iter5 (`cap_pool resolution-change race latent under untested consumer probe patterns`) was prescient — this is exactly that race, made hard-failing by iter6/7's additions. iter9 input.
2. **dmabuf-wayland↔KWin presentation handoff produces solid green** — independent of libva. Filed at [marfrit/libva-multiplanar#1](https://git.reauktion.de/marfrit/libva-multiplanar/issues/1). `mpv --hwdec=v4l2request --vo=dmabuf-wayland` (libva-bypassed, ffmpeg's native V4L2 hwaccel) **also** produces solid green frames on ohm/KWin 6. `mpv --hwdec=v4l2request --vo=gpu` displays the correct picture (slow, GPU shader path on Mali-G52). So the green is dmabuf-wayland-specific, not decoder-side. KWin's `linux-dmabuf-v1` advertised list contains only `NV12 LINEAR (modifier 0x0)` — likely an NV12 modifier/pitch handshake regression somewhere between iter5 close (2026-05-05, "mpv `--hwdec=vaapi` smooth") and now. Could be on the libva side (vaExportSurfaceHandle modifier reporting), the ffmpeg side (drm_prime export modifier), or KWin/Mesa-panfrost upgrade since 2026-05-05.
2. **dmabuf-wayland↔KWin presentation handoff produces solid green** — independent of libva. Filed at [marfrit/libva-multiplanar#1](https://git.reauktion.de/marfrit/libva-multiplanar/issues/1); triage moved to dedicated peer campaign [`~/src/dmabuf-modifier-triage/`](../dmabuf-modifier-triage/) (Gitea: [marfrit/dmabuf-modifier-triage](https://git.reauktion.de/marfrit/dmabuf-modifier-triage)) opened 2026-05-08. Smoking gun identified at scaffold time: kwin-fourier currently ships `0001-transaction-bypass-watchDmaBuf-fence-wait.patch` active, which bypasses KWin's implicit-sync fence wait on dmabufs — a runtime-observable race that fits the symptom. Triage Phase 0 item 1 is the stock-kwin A/B that decides it. Doesn't gate libva-multiplanar iter9.
**Working ohm HW-decode path right now (workaround):**