# dmabuf-modifier-triage

## TL;DR

Focused triage campaign for **[marfrit/libva-multiplanar#1](https://git.reauktion.de/marfrit/libva-multiplanar/issues/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](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/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`](../../.claude/projects/-home-mfritsche-src/memory/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`](../../.claude/projects/-home-mfritsche-src-kwin-overlay-subsurface/memory/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/`](../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/`](../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/`](../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`](../../.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.