diff --git a/README.md b/README.md
index 98135dc..1e2e9ea 100644
--- a/README.md
+++ b/README.md
@@ -58,7 +58,7 @@ The iter8 close (`65969da3`) was packaged as `libva-v4l2-request-fourier-1.0.0.r
 
 1. **libva cap_pool / REQBUFS / iter6-REINIT lifecycle cascade** — filed at [marfrit/libva-v4l2-request-fourier#1](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/1). Under `mpv --hwdec=vaapi` interactive playback, `cap_pool_init` runs twice for slots 0..23 (probe-context + decode-context, no teardown between), `VIDIOC_REQBUFS` returns EBUSY (queue still STREAMON'd), iter6's per-OUTPUT-slot REINIT (commit `a09c03c`) chokes on a Bad fd, OUTPUT queue (`type=9`) hits ENOMEM after a few REQBUFS retries, decode aborts with `Failed to create surface: 2 (resource allocation failed)`. The Phase-5-sonnet-C4 caveat from iter5 (`cap_pool resolution-change race latent under untested consumer probe patterns`) was prescient — this is exactly that race, made hard-failing by iter6/7's additions. iter9 input.
 
-2. **dmabuf-wayland↔KWin presentation handoff produces solid green** — independent of libva. `mpv --hwdec=v4l2request --vo=dmabuf-wayland` (libva-bypassed, ffmpeg's native V4L2 hwaccel) **also** produces solid green frames on ohm/KWin 6. `mpv --hwdec=v4l2request --vo=gpu` displays the correct picture (slow, GPU shader path on Mali-G52). So the green is dmabuf-wayland-specific, not decoder-side. KWin's `linux-dmabuf-v1` advertised list contains only `NV12 LINEAR (modifier 0x0)` — likely an NV12 modifier/pitch handshake regression somewhere between iter5 close (2026-05-05, "mpv `--hwdec=vaapi` smooth") and now. Could be on the libva side (vaExportSurfaceHandle modifier reporting), the ffmpeg side (drm_prime export modifier), or KWin/Mesa-panfrost upgrade since 2026-05-05. Not yet filed — needs separate triage.
+2. **dmabuf-wayland↔KWin presentation handoff produces solid green** — independent of libva. Filed at [marfrit/libva-multiplanar#1](https://git.reauktion.de/marfrit/libva-multiplanar/issues/1). `mpv --hwdec=v4l2request --vo=dmabuf-wayland` (libva-bypassed, ffmpeg's native V4L2 hwaccel) **also** produces solid green frames on ohm/KWin 6. `mpv --hwdec=v4l2request --vo=gpu` displays the correct picture (slow, GPU shader path on Mali-G52). So the green is dmabuf-wayland-specific, not decoder-side. KWin's `linux-dmabuf-v1` advertised list contains only `NV12 LINEAR (modifier 0x0)` — likely an NV12 modifier/pitch handshake regression somewhere between iter5 close (2026-05-05, "mpv `--hwdec=vaapi` smooth") and now. Could be on the libva side (vaExportSurfaceHandle modifier reporting), the ffmpeg side (drm_prime export modifier), or KWin/Mesa-panfrost upgrade since 2026-05-05.
 
 **Working ohm HW-decode path right now (workaround):**