Operator decision 2026-05-08: the iter1 fix is shipped only when frame
10 of the bbb fixture under --vo=dmabuf-wayland matches the expected
reference (captured via --vo=gpu on same hardware/session).
- screenshots/frame10_dmabuf_green.png — current broken state
- screenshots/frame10_expected.png — target post-fix state
- screenshots/README.md — verification protocol (SSIM > 0.95 + valid
WAYLAND_DEBUG .add() semantics + no regression on vo=gpu / vo=wlshm)
- phase0_findings.md — references the criterion in the conclusion section
This locks the campaign's deliverable. Patches that change wire-protocol
.add() shape but don't restore the picture do not satisfy iter1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reference image of the bug as visible on ohm. Captured 2026-05-08 via
mpv --hwdec=v4l2request --vo=dmabuf-wayland --pause --start=00:00:00.42
--fullscreen fourier-test/bbb_1080p30_h264.mp4 then spectacle -b -f -n.
Uniform dark green at approx RGB(0, 75, 0) — exactly what the all-zero
NV12 hypothesis (Y=U=V=0 through BT.601/709 conversion) predicts and
what marfrit/dmabuf-modifier-triage#1 diagnoses (KWin reads past-EOF
on the UV plane fd, returns zeros for chroma).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Eight directed A/B tests on ohm ruled out every layer that doesn't
matter (libva, decoder content, color tags, kwin-fourier 0001 patch,
Mesa 26.0.6 vs 26.0.5, Wayland generally, kernel 6.19.10 vs 7.0,
KWin Vulkan vs OpenGL backend). WAYLAND_DEBUG=1 capture surfaced the
real bug at the protocol-message layer:
add(fd 41, plane=0, offset=0, stride=1920, mod=0,0)
add(fd 42, plane=1, offset=2088960, stride=1920, mod=0,0)
mpv mixes per-plane fds (V4L2 MPLANE export semantics) with
single-allocation offset for plane 1 (single-fd export semantics).
KWin reads UV from past-EOF on the UV-plane fd → all-zero NV12 →
dark green render (Y=U=V=0 in BT.601/709 ≈ RGB(0,70,0)).
Filed at marfrit/dmabuf-modifier-triage#1 with full diagnosis +
suggested fix path. Iter1 fix work is blocked on libva-multiplanar
iter9 (need clean libva path to verify which producer is at fault
or whether mpv VO is the sole bug). Working interim path is
mpv --hwdec=v4l2request --vo=gpu (correct picture, slow shader path).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User runs kwin-fourier with active patch
0001-transaction-bypass-watchDmaBuf-fence-wait.patch — this bypasses
KWin's implicit-sync fence wait on dmabufs. If KWin samples a hantro
CAPTURE buffer before the decoder fence signals, it gets all-zeros
NV12 which renders solid green in YUV→RGB. This is the most likely
cause and is decisively testable via a stock-kwin A/B (item 1).
Hypothesis: pre-iter5 the libva path was masked because vaSyncSurface
provided ordering. iter6/7 may have changed that. Both libva and
ffmpeg-v4l2request paths now expose the lack of fence-wait.
Run-history breadcrumb (#51 introduce, #58 switch to 0002, #59 revert
to 0001) recorded in the findings doc.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Focused triage of marfrit/libva-multiplanar#1 — dmabuf-wayland green
on ohm independent of decoder backend. Locked question: identify the
layer responsible (libva / ffmpeg / KWin / Mesa-panfrost / kernel)
and file upstream where appropriate. Performance is explicitly out of
scope — user has working slow path via vo=gpu hwdec=v4l2request.
Phase 0 deliverables: vaExportSurfaceHandle + AVDRMFrameDescriptor
modifier captures, Wayland linux-dmabuf-v1 advertise snapshot, pacman
upgrade timeline review for the iter5→iter8 regression window, and
stock-kwin A/B isolating kwin-fourier as a candidate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit