dmabuf-modifier-triage

TL;DR

Focused triage campaign for marfrit/libva-multiplanar#1 — mpv --vo=dmabuf-wayland produces solid green frames on ohm regardless of decoder backend (--hwdec=vaapi, --hwdec=v4l2request). --vo=gpu displays correct content. The bug is squarely in the dmabuf-wayland↔KWin presentation handoff, not in the decoder.

This campaign exists because libva-multiplanar's iter9 was scoped narrowly to fix its own decoder-side cap_pool/REQBUFS cascade (marfrit/libva-v4l2-request-fourier#1) and shouldn't bloat to take on the presentation-layer bug. KWin/panfrost stack work is also explicitly out-of-scope for libva-multiplanar per its Out-of-scope README section.

Locked 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.

Performance / "make smooth" is explicitly out of this campaign — the goal is bisection-down to the offending layer + a recorded fix or upstream filing per layer. The user's working HW-decode workflow on ohm right now is --vo=gpu --hwdec=v4l2request (slow but correct), which is sufficient until this campaign lands.

Hardware target

• ohm — PineTab2, Rockchip RK3566 (note: prior README references to RK3568 corrected per ~/src/libva-multiplanar/libva-v4l2-request-fourier/ commit dcaa1f1). hantro G1 decoder, Mali-G52 (Bifrost) GPU via panfrost.
• KWin 6.x via Plasma 6 Wayland.
• Reproducer: ~/fourier-test/bbb_1080p30_h264.mp4 (Pinebook Pro / ohm shared corpus from ohm_gl_fix campaign).

Other hosts may serve as A/B controls (different GPU + same decoder, or same GPU + different decoder) — see phase0_findings.md for the planned matrix.

Process

8(+1) phase loop per feedback_dev_process.md. Phase 0 = locked-question + substrate. Phase 5 review uses the sonnet-architect subagent pattern.

In-session-acquired data discipline per feedback_replicate_baseline_first.md: the libva-multiplanar campaign's decoder-side measurements are reference history, not threshold sources for this campaign's cells.

Predecessor work this campaign builds on

• ../libva-multiplanar/ — closed iter1..iter5 + iter6/7/8 work on the libva-v4l2-request-fourier fork. The campaign's iter5/8 close claimed "mpv --hwdec=vaapi smooth" on ohm — that claim is what was found to fail on 2026-05-08, with the green being one of the two failure modes (the other is the libva cascade, separately tracked at iter9). Cross-link from libva-multiplanar README's "Known issues at iter8 production tip" section.
• ../kwin-overlay-subsurface/ — closed without patch. phase2_source_findings.md covers PineTab2's rockchip-drm plane format/modifier table. Plane 39 (Primary, NV12 LINEAR) is the only NV12-capable scanout. Useful because the modifier negotiation we're triaging here may overlap with the scanout-plane-modifier facts that campaign captured.
• ../x11-session-research/ — confirmed the scanout-plane gap isn't fixable by switching session servers. Also useful negative space: this triage shouldn't waste cycles on "switch off Wayland" experiments that the predecessor already ran.
• ~/.claude/projects/-home-mfritsche-src-fourier/memory/project_libva_multiplanar_state.md — campaign-state memory captures the package shipped + both bugs found.

External reference:

• mpv --vo=dmabuf-wayland source: https://github.com/mpv-player/mpv/blob/master/video/out/vo_dmabuf_wayland.c
• KWin Wayland linux-dmabuf-v1 source: KDE kwin/src/wayland/linuxdmabufv1clientbuffer.cpp
• Mesa panfrost modifier handling: src/panfrost/lib/genxml/decode_* etc.
• Linux DRM modifier registry: include/uapi/drm/drm_fourcc.h (DRM_FORMAT_MOD_*)

Repository layout

~/src/dmabuf-modifier-triage/                  <- this campaign (its own git repo)
├── README.md                                  <- this file
├── phase0_findings.md                         <- locked question + Phase 0 work list
├── (worklist.md, phase[2-8]*.md as phases land)
└── (no fork code lives here — bug is presentation-side, not in libva-v4l2-request-fourier;
     fixes either land upstream or in kwin-fourier / panfrost-side packages)

The campaign repo stays separate from any fork. If a fix lands as a downstream patch, it lives in ~/src/marfrit-packages/arch/<package>/ (kwin-fourier, mesa, etc.) per the existing fourier umbrella convention, with a pointer back to this campaign's findings.

Operator-facing repo URL: git.reauktion.de/marfrit/dmabuf-modifier-triage — created empty during scaffolding, no push until first iteration finds something worth publishing.

Non-upstreaming default

Inherited from feedback_no_upstream.md. Exception: when triage proves the bug is upstream code (KWin / Mesa-panfrost / kernel), opening a properly-formatted upstream bug report is the only useful outcome of that line of investigation, so this campaign explicitly does plan upstream filings as deliverables when scope-correct. Upstream submissions land in ~/src/marfrit-packages/upstream-submissions/dmabuf-modifier-triage/ per the existing convention.

Build infrastructure

No build host needed — this is a triage campaign, not a code-bearing one. Reproductions run on ohm directly. If a kwin-fourier rebuild is required for an A/B test, the existing boltzmann + marfrit-publish path applies.