From 9f406c0c4236bd79cbaf769d43920324da63c885 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Fri, 8 May 2026 19:01:12 +0000 Subject: [PATCH] =?UTF-8?q?phase0:=20revise=20framing=20=E2=80=94=20iter1?= =?UTF-8?q?=20is=20unblocked,=20libva=20comparison=20is=20follow-up=20vali?= =?UTF-8?q?dation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Operator pushback: phase 0 should unblock iter1, not gate it. The locked question is "fix what's locally in scope" — kill the green, not just identify a layer. The captured wl_dmabuf message is internally inconsistent on its own (per-plane fds + single-allocation offset for plane 1 is a contradiction no valid producer can claim simultaneously). mpv's translation layer produces this regardless of which producer feeds it, so iter1 can write the fix from the ffmpeg- side data alone. The libva-path WAYLAND_DEBUG comparison after iter9 is a follow-up validation that confirms the fix handles both producer shapes, not a prerequisite for writing it. Co-Authored-By: Claude Opus 4.7 (1M context) --- phase0_findings.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/phase0_findings.md b/phase0_findings.md index d57d793..9dd22b3 100644 --- a/phase0_findings.md +++ b/phase0_findings.md @@ -40,11 +40,9 @@ create_immed(wl_buffer#56, 1920, 1080, NV12, flags=0) - mpv's `vo=dmabuf-wayland` is the unique broken path because it constructs the wl_dmabuf protocol message itself, mishandling the producer's plane semantics. - mpv's `vo=wlshm` is fine because it goes through CPU memcpy, bypassing the dmabuf protocol entirely. -**Deferred verifier (gates iter1's actual fix):** +**iter1 is unblocked.** The wl_dmabuf message in the WAYLAND_DEBUG trace is internally inconsistent on its own — combining per-plane fds with a single-allocation offset for plane 1 is something no valid producer can claim simultaneously. mpv's translation layer produces this regardless of which producer feeds it. The fix can be written from the ffmpeg-side data alone. -Re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` (libva path) once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback. If both paths produce the same wrong `.add()` pattern → bug is purely in mpv VO. If only one does → that path's producer (libva or ffmpeg V4L2 hwaccel respectively) is the bug. - -This means iter1's fix work cannot start until libva-multiplanar iter9 lands. dmabuf-modifier-triage iter1 is **blocked-on**: libva-multiplanar/iter9. +**Follow-up validation (not a prerequisite):** once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback, re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` to confirm the same fix also handles the libva path. If both paths produce the same wrong `.add()` pattern → fix is correct. If only one does → expand the fix to handle both producer shapes (the AVDRMFrameDescriptor and VADRMPRIMESurfaceDescriptor mappings to wl_dmabuf may need separate logic). **Working ohm HW-decode workflow until fix lands:**