dmabuf-modifier-triage/phase0_findings.md

Phase 0 — locked research question, substrate, deliverables

Locked 2026-05-08. Iter1 phase 0 substrate.

Locked research question

Identify the layer responsible for the dmabuf-wayland green on ohm — libva (vaExportSurfaceHandle modifier reporting), ffmpeg V4L2 request hwaccel (AVDRMFrameDescriptor modifier), KWin (linux-dmabuf-v1 accept logic), Mesa-panfrost (modifier import constraints), or the kernel hantro driver (buffer attribute reporting). File upstream where appropriate; fix what's locally in scope.

Bug tracker: marfrit/libva-multiplanar#1.

Reproduction (verbatim from issue tracker)

# All three on ohm with libva-v4l2-request-fourier-1.0.0.r280.65969da-1
# from [marfrit] and /etc/profile.d/libva-v4l2-request.sh in effect.

# 1. via libva — green (also hits libva-v4l2-request-fourier#1, but green
#    would persist even with that bug fixed)
mpv --hwdec=vaapi --vo=dmabuf-wayland --target-colorspace-hint=no \
    fourier-test/bbb_1080p30_h264.mp4

# 2. via ffmpeg V4L2 request hwaccel — also green (no libva)
mpv --hwdec=v4l2request --vo=dmabuf-wayland \
    fourier-test/bbb_1080p30_h264.mp4

# 3. via ffmpeg V4L2 request hwaccel + GPU shader VO — correct picture (slow)
mpv --hwdec=v4l2request --vo=gpu \
    fourier-test/bbb_1080p30_h264.mp4

Result #3 is the workaround currently in use. The campaign closes when result #1 displays correctly.

Open questions

1. What modifier does libva's vaExportSurfaceHandle report for the hantro decode surface on ohm? Should be DRM_FORMAT_MOD_LINEAR (0x0) per iter2 Fix 2's pitch-aligned path, but the green suggests otherwise. Need a vainfo-equivalent or a small C harness that calls vaCreateSurfaces + vaExportSurfaceHandle and prints the VADRMPRIMESurfaceDescriptor.objects[i].drm_format_modifier.

2. What modifier does ffmpeg's V4L2 request hwaccel report for the same decode? Captured via AV_HWFRAME_TRANSFER_DIRECTION_FROM + inspecting the AVDRMFrameDescriptor.objects[i].format_modifier. Probably comes from VIDIOC_G_FMT(CAPTURE_MPLANE) plus a hardcoded LINEAR if v4l2 doesn't report a modifier.

3. What modifier does KWin advertise via zwp_linux_dmabuf_v1.modifier? From mpv -v output we already know the answer is "NV12 with modifier 0x0 only." But it's worth confirming via wayland-info that this is the only advertised entry, and capturing whether KWin also supports DRM_FORMAT_MOD_INVALID as the catch-all.

4. Does KWin reject the buffer outright (protocol error) or accept and display garbage? From wp_linux_dmabuf protocol perspective: the answer is in the surface's per-commit feedback. Strace KWin's compositor or use a WAYLAND_DEBUG=1 mpv run to capture the protocol exchange.

5. Is the bug in the modifier handshake or in the buffer's content interpretation? Specifically: if KWin accepts the buffer but renders it wrong, the issue is interpretation (likely Mali-G52 panfrost's NV12 sampler reading raw pixels assuming a stride/layout that doesn't match). If KWin rejects, the issue is negotiation (mpv claims a modifier KWin won't accept).

6. Has KWin or Mesa-panfrost been upgraded between iter5 close (2026-05-05) and now (2026-05-08)? A pacman -Q log + pacman.log review on ohm tells us whether new package versions correlate with the iter5→iter8 regression window. The kwin-fourier version on ohm (probably 1:6.6.4-1 per packages.reauktion.de) needs cross-checking against the version that was "smooth" at iter5.

7. Does a non-fourier KWin (stock arch kwin 1:6.6.4-1) exhibit the same green? The kwin-fourier 0001 patch is the known-distinguishing change; pinning back to stock kwin and re-testing isolates whether kwin-fourier introduced the issue.

8. Does wlroots-based compositor (sway, weston) show the green too? Switches the compositor variable. If green there, it's not KWin-specific. If correct there, KWin is the suspect.

Phase 0 will deliver

1. vaExportSurfaceHandle modifier capture — small C harness in phase0_evidence/<date>/va_modifier_probe.c linked against libva, prints the DRM_PRIME_2 descriptor for a freshly-allocated NV12 surface on ohm. Captured output goes to phase0_evidence/<date>/va_modifier_capture.md.

2. AVDRMFrameDescriptor modifier capture — small C harness using ffmpeg's av_hwframe_transfer_data against a /dev/media0 + /dev/video1 hwdevice context, prints the modifier ffmpeg reports. Output to phase0_evidence/<date>/av_modifier_capture.md.

3. Wayland linux-dmabuf-v1 advertised list — wayland-info snapshot + WAYLAND_DEBUG=1 mpv ... excerpt showing the negotiation. Output to phase0_evidence/<date>/kwin_dmabuf_advertise.md.

4. Pacman upgrade timeline review — journalctl _COMM=pacman or cat /var/log/pacman.log | awk '$1>="[2026-05-05"' on ohm to see what changed between iter5 close and now. Output to phase0_evidence/<date>/pacman_upgrade_window.md.

5. Stock-kwin A/B — temporarily swap kwin-fourier for stock arch kwin, re-run reproduction, capture result. Output to phase0_evidence/<date>/kwin_fourier_ab.md.

6. Compositor A/B (optional) — if items 1-5 don't conclude, swap compositor (sway via TTY login session) and capture. Output to phase0_evidence/<date>/compositor_ab.md.

Items 1-2 are decoder-side captures (~30 min each). Items 3-4 are 5 min each. Items 5-6 are bigger because they require login-session swaps.

After Phase 0 closes, Phase 1 will reproduce on a controlled test rig (probably mpv -v with WAYLAND_DEBUG=1, deterministic frame count, structured output capture) so Phase 4's fix attempt has a clean signal-to-noise environment.

Phase 0 cross-references

• libva-multiplanar phase0_findings.md — Phase 0 / Phase 2 substrate for the original campaign. The decoder-side facts there are reference (modifier reporting in iter2 Fix 2, NV12 multi-planar paths).
• kwin-overlay-subsurface phase2_source_findings.md — modifier table for PineTab2's rockchip-drm planes. Plane 39 (Primary, NV12 LINEAR) is the only NV12-capable scanout; this campaign's bug may be related to whether the dmabuf reaches Plane 39 vs goes through GL composition (the predecessor verdict was "no NV12-capable Overlay plane, so KWin always GL-composites").
• libva-multiplanar iter5 phase8_iteration5_close.md — last close date 2026-05-05 with the "mpv smooth" claim. Verifying that the date stamp is correct and the test was run interactively (not just via the perf binding cell) is one of Phase 0's housekeeping tasks.

Out-of-scope reminders

• Performance / "make it smooth": this campaign is correctness-only. The user already has --vo=gpu --hwdec=v4l2request as a working slow path.
• Decoder-side bugs: those belong to libva-multiplanar iter9. Anything that turns out to be vaExportSurfaceHandle lying about the modifier hands the bug back to iter9.
• Other hardware: ohm is the locked target. fresnel (RK3399, Mali-T860 Midgard) and ampere (RK3588) may or may not exhibit the same — note in cross-campaign memory if they do, but don't expand scope to fix on those hosts.
• AV1 / VP9 / HEVC dmabuf paths: H.264 only for this triage.