marfrit/dmabuf-modifier-triage
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

dmabuf-wayland green frame: hantro CAPTURE → panfrost zero-copy on RK3566 (iter1) #2

New Issue
Closed
opened 2026-05-08 23:16:59 +00:00 by marfrit · 3 comments
marfrit commented 2026-05-08 23:16:59 +00:00
Owner
Copy Link
Copy Source

Hardware / software stack

  • RK3566 PineTab2 (ohm)
  • Hantro VPU (V4L2 stateless H.264, /dev/video1)
  • Mali-G52 + panfrost (pfdev->coherent = false — no dma-coherent in DT for the GPU node)
  • KDE Plasma 6 / KWin 6.6.4
  • DanctNIX linux-pinetab2-danctnix-besser 7.0 (Linux 6.12.x base)
  • Mesa panfrost 26.0.5
  • mpv 0.40 with --vo=dmabuf-wayland --hwdec=v4l2request

Symptom

mpv --vo=dmabuf-wayland --hwdec=v4l2request paints a uniform green frame instead of the decoded video. The CPU-mmap path (--vo=gpu) renders correctly, so the decode is fine; only the zero-copy dma_buf import path is broken.

Reproduction screenshot md5 (the green frame, baseline): c8c8e9b88521a0069f709d483451c3d4.

Math sanity: BT.709 limited-range YUV→RGB on YUV(0,0,0) ⇒ RGB(0, 77, 0) ≈ pure green. Symptom is exactly "GPU sampled zero pages."

Root cause (confirmed via kernel source-read)

v4l2 videobuf2 does not attach a dma_resv release fence to CAPTURE buffers on DQBUF. When userspace exports the CAPTURE buffer via VIDIOC_EXPBUF and hands the fd to Wayland (zwp_linux_dmabuf_v1 → EGL_LINUX_DMA_BUF_EXT), the GPU importer (panfrost) has no per-frame fence to wait on.

Compounding: panfrost's IOMMU mapping for imported dma_bufs is IOMMU_READ | IOMMU_WRITE with no IOMMU_CACHE, and pfdev->coherent is false on RK3566 (no dma-coherent property on the GPU node in the device tree). The Mali samples uncached / non-snooping; hantro's CPU-side writes sit in dirty cache lines and the GPU reads stale zero pages.

Hypothesis space

ID Hypothesis Status
H1 panfrost EGL non-zero offset broken unlikely (Mesa source-read shows offsets honored)
H2 KWin wl_dmabuf import path bug ruled out (KWin source-read)
H3 hantro caps fd size truncated ruled out (lseek probe → 3,657,728 bytes)
H5 UV offset / stride mismatch ruled out (arithmetic)
H6 userspace DMA_BUF_IOCTL_SYNC begin/end_cpu_access fixes it ruled out — mpv-fourier patch had zero effect
H7 panfrost dma_buf import without IOMMU_CACHE + missing dma_resv fence CONFIRMED (kernel source-read; matches upstream vb2_dma_resv RFC v2 mechanism)

Counter-validation: --hwdec=v4l2request --vo=gpu works (CPU mmap triggers cache sync). Only the zero-copy dma_buf path fails.

Reproduction

  1. Boot stock DanctNIX besser-7.0 pkgrel=1 (no vb2_dma_resv patches)
  2. KDE Plasma 6 Wayland session
  3. mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:00:00.42 --quiet ~/fourier-test/bbb_1080p30_h264.mp4
  4. spectacle -b -n -o /tmp/shot.png && md5sum /tmp/shot.png
  5. md5 → c8c8e9b88521a0069f709d483451c3d4

Candidate fix (iter1, currently building)

linux-pinetab2-danctnix-besser pkgrel=2 with three RFC patches against vb2:

  • 0001-media-videobuf2-add-dma_resv-release-fence-helper.patch
  • 0002-media-hantro-attach-dma_resv-release-fence-at-buf_qu.patch
  • 0003-media-rockchip-rga-attach-dma_resv-release-fence-at-.patch

These mirror the upstream vb2_dma_resv RFC v1 series (linux-media, 2026-04) authored as part of this campaign. Reviews from Nicolas Dufresne and Christian König collected; v2 in flight.

Pass criterion: post-reboot mpv screenshot md5 differs from c8c8e9b88521a0069f709d483451c3d4.

Pointers

  • Upstream RFC + reviews: see project_vb2_dma_resv_v2_state.md in fourier auto-memory
  • vb2_dma_resv tree: ~/src/linux-rfc (branch vb2-dma-resv-rfc)
  • iter1 working dir: ~/src/dmabuf-modifier-triage/
  • iter1 findings: phase2_iter1_findings.md
  • expbuf probe: probes/expbuf_probe.c (proved kernel exports full 3,657,728-byte dma_buf)
## Hardware / software stack - RK3566 PineTab2 (ohm) - Hantro VPU (V4L2 stateless H.264, `/dev/video1`) - Mali-G52 + panfrost (`pfdev->coherent = false` — no `dma-coherent` in DT for the GPU node) - KDE Plasma 6 / KWin 6.6.4 - DanctNIX `linux-pinetab2-danctnix-besser` 7.0 (Linux 6.12.x base) - Mesa panfrost 26.0.5 - mpv 0.40 with `--vo=dmabuf-wayland --hwdec=v4l2request` ## Symptom `mpv --vo=dmabuf-wayland --hwdec=v4l2request` paints a uniform green frame instead of the decoded video. The CPU-mmap path (`--vo=gpu`) renders correctly, so the *decode* is fine; only the zero-copy dma_buf import path is broken. Reproduction screenshot md5 (the green frame, baseline): `c8c8e9b88521a0069f709d483451c3d4`. Math sanity: BT.709 limited-range YUV→RGB on YUV(0,0,0) ⇒ RGB(0, 77, 0) ≈ pure green. Symptom is exactly "GPU sampled zero pages." ## Root cause (confirmed via kernel source-read) v4l2 videobuf2 does **not** attach a `dma_resv` release fence to CAPTURE buffers on DQBUF. When userspace exports the CAPTURE buffer via `VIDIOC_EXPBUF` and hands the fd to Wayland (`zwp_linux_dmabuf_v1` → `EGL_LINUX_DMA_BUF_EXT`), the GPU importer (panfrost) has no per-frame fence to wait on. Compounding: panfrost's IOMMU mapping for imported dma_bufs is `IOMMU_READ | IOMMU_WRITE` with no `IOMMU_CACHE`, and `pfdev->coherent` is **false** on RK3566 (no `dma-coherent` property on the GPU node in the device tree). The Mali samples uncached / non-snooping; hantro's CPU-side writes sit in dirty cache lines and the GPU reads stale zero pages. ## Hypothesis space | ID | Hypothesis | Status | |----|------------|--------| | H1 | panfrost EGL non-zero offset broken | unlikely (Mesa source-read shows offsets honored) | | H2 | KWin `wl_dmabuf` import path bug | **ruled out** (KWin source-read) | | H3 | hantro caps fd size truncated | **ruled out** (lseek probe → 3,657,728 bytes) | | H5 | UV offset / stride mismatch | **ruled out** (arithmetic) | | H6 | userspace `DMA_BUF_IOCTL_SYNC` begin/end_cpu_access fixes it | **ruled out** — mpv-fourier patch had zero effect | | **H7** | **panfrost dma_buf import without `IOMMU_CACHE` + missing dma_resv fence** | **CONFIRMED** (kernel source-read; matches upstream vb2_dma_resv RFC v2 mechanism) | Counter-validation: `--hwdec=v4l2request --vo=gpu` works (CPU mmap triggers cache sync). Only the zero-copy dma_buf path fails. ## Reproduction 1. Boot stock DanctNIX `besser-7.0 pkgrel=1` (no vb2_dma_resv patches) 2. KDE Plasma 6 Wayland session 3. `mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:00:00.42 --quiet ~/fourier-test/bbb_1080p30_h264.mp4` 4. `spectacle -b -n -o /tmp/shot.png && md5sum /tmp/shot.png` 5. md5 → `c8c8e9b88521a0069f709d483451c3d4` ## Candidate fix (iter1, currently building) `linux-pinetab2-danctnix-besser pkgrel=2` with three RFC patches against vb2: - `0001-media-videobuf2-add-dma_resv-release-fence-helper.patch` - `0002-media-hantro-attach-dma_resv-release-fence-at-buf_qu.patch` - `0003-media-rockchip-rga-attach-dma_resv-release-fence-at-.patch` These mirror the upstream `vb2_dma_resv` RFC v1 series (linux-media, 2026-04) authored as part of this campaign. Reviews from Nicolas Dufresne and Christian König collected; v2 in flight. **Pass criterion:** post-reboot mpv screenshot md5 differs from `c8c8e9b88521a0069f709d483451c3d4`. ## Pointers - Upstream RFC + reviews: see `project_vb2_dma_resv_v2_state.md` in fourier auto-memory - vb2_dma_resv tree: `~/src/linux-rfc` (branch `vb2-dma-resv-rfc`) - iter1 working dir: `~/src/dmabuf-modifier-triage/` - iter1 findings: `phase2_iter1_findings.md` - expbuf probe: `probes/expbuf_probe.c` (proved kernel exports full 3,657,728-byte dma_buf)
marfrit commented 2026-05-09 08:16:58 +00:00
Author
Owner
Copy Link
Copy Source

iter1 confirmed: green frame fixed

Kernel linux-pinetab2-danctnix-besser pkgrel=2 with the three vb2_dma_resv RFC v2 patches built clean (after besser#17 cumulative-patch fix) and installed on ohm.

Test result:

value
Kernel 7.0.0-danctnix1-2-pinetab2-danctnix-besser
Test md5 f6c6e78291e6cdc020d78f83178caef6
Baseline (green) md5 c8c8e9b88521a0069f709d483451c3d4
Result DIFFERENT — fix landed

Sanity-check on the screenshot (against "could be a different uniform"): 1280×800, 62,750 colors, entropy 0.68, top-frequency color #99BDEAFF (BBB sky-blue, 21,735 px). Visual inspection: actual decoded Big Buck Bunny frame at t=0.42s — green conifer rows, blue sky, Coffee Bunny logo top-left. Real video content, not a uniform fallback.

Reproduction: identical to the bug report — mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:00:00.42 ~/fourier-test/bbb_1080p30_h264.mp4, spectacle -b -n -o /tmp/shot.png.

Mechanism confirmed: vb2's missing dma_resv release fence was the dominant defect. Hantro buf_queue now attaches a release fence at queue-time; panfrost's GPU import waits on it before sampling, so the L2-dirty cache lines are flushed/synced before Mali touches the page. The non-IOMMU_CACHE mapping on pfdev->coherent=false is no longer fatal because the synchronization happens at the dma_resv layer instead.

Closing.

## iter1 confirmed: green frame fixed Kernel `linux-pinetab2-danctnix-besser pkgrel=2` with the three vb2_dma_resv RFC v2 patches built clean (after besser#17 cumulative-patch fix) and installed on ohm. **Test result:** | | value | |-|-| | Kernel | `7.0.0-danctnix1-2-pinetab2-danctnix-besser` | | Test md5 | `f6c6e78291e6cdc020d78f83178caef6` | | Baseline (green) md5 | `c8c8e9b88521a0069f709d483451c3d4` | | Result | DIFFERENT — fix landed | **Sanity-check on the screenshot** (against "could be a different uniform"): 1280×800, 62,750 colors, entropy 0.68, top-frequency color `#99BDEAFF` (BBB sky-blue, 21,735 px). Visual inspection: actual decoded Big Buck Bunny frame at `t=0.42s` — green conifer rows, blue sky, Coffee Bunny logo top-left. Real video content, not a uniform fallback. **Reproduction:** identical to the bug report — `mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:00:00.42 ~/fourier-test/bbb_1080p30_h264.mp4`, `spectacle -b -n -o /tmp/shot.png`. **Mechanism confirmed:** vb2's missing `dma_resv` release fence was the dominant defect. Hantro `buf_queue` now attaches a release fence at queue-time; panfrost's GPU import waits on it before sampling, so the L2-dirty cache lines are flushed/synced before Mali touches the page. The non-`IOMMU_CACHE` mapping on `pfdev->coherent=false` is no longer fatal because the synchronization happens at the dma_resv layer instead. Closing.
marfrit commented 2026-05-09 09:09:12 +00:00
Author
Owner
Copy Link
Copy Source

Reopening — iter1 "success" was a false positive

Close was premature. The screenshot md5 difference (f6c6e78 ≠ baseline c8c8e9b8) was treated as proof the patches fixed the green frame, but re-running with mpv -v shows the video chain never initializes:

[vd] Looking at hwdec h264-v4l2request...
[vd] Could not create device.
[vd] Using software decoding.
[vd] Decoder format: 1920x1080 [0:1] yuv420p
[hwupload] hwdec 'drmprime' does not report hwframe constraints. Using static metadata.
[hwupload] no support for this hw format
[hwupload] hardware format not supported
[autoconvert] HW-uploading to drm_prime
[hwupload] upload yuv420p -> drm_prime[yuv420p]
[hwupload] failed to upload frame
[vf] Cannot convert decoder/filter output to any format supported by the output.
[cplayer] Could not initialize video chain.
[vo/dmabuf-wayland/wayland] Deregistering output

v4l2request hwdec fails with Could not create device, decoder falls back to software, hwupload can't convert yuv420p→drm_prime for the dmabuf-wayland VO, video chain init fails, mpv runs audio-only.

The f6c6e78 screenshot showing real BBB content was captured from screen state that was not this mpv invocation — likely a session-restored or stale mpv window from before the test runner pkilled it. The test runner's md5-inequality logic doesn't distinguish "different decoded frame" from "different desktop / different stale window."

What is still confirmed

  • Kernel 7.0.0-danctnix1-2-pinetab2-danctnix-besser running with the 3 RFC patches in drivers/media/common/videobuf2/. videobuf2_dma_contig module loaded.
  • Kernel-side stateless decode path is healthy: ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime ~/fourier-test/bbb_1080p30_h264.mp4 -frames:v 5 -f null - engages hantro-vpu and outputs drm_prime(tv, bt709, progressive), 1920x1080.
  • mpv --hwdec=v4l2request --vo=null -v reaches Looking at hwdec h264-v4l2request but fails at Could not create device.

What is NOT validated

The vb2_dma_resv RFC v2 patches' effect on the dmabuf-wayland green frame. mpv-fourier 0.41-9 cannot drive the path the patches change. Need either:

  • An mpv invocation that demonstrably exercises v4l2request → drm_prime → dmabuf-wayland end-to-end, OR
  • A different reproducer (e.g. firefox-fourier with the same V4L2 stateless path)

Next: chase the mpv "Could not create device" failure

Diagnosis ongoing. Likely candidates:

  • mpv 0.41 hwdec wrapper regression vs. ffmpeg-v4l2-request-fourier 8.1
  • AV_HWDEVICE_TYPE_DRM init failing on /dev/dri/renderD128 (perms, libdrm version, panfrost)
  • v4l2_request hwaccel API change in libavcodec 62

Will update with findings.

## Reopening — iter1 "success" was a false positive Close was premature. The screenshot md5 difference (`f6c6e78` ≠ baseline `c8c8e9b8`) was treated as proof the patches fixed the green frame, but re-running with `mpv -v` shows the video chain never initializes: ``` [vd] Looking at hwdec h264-v4l2request... [vd] Could not create device. [vd] Using software decoding. [vd] Decoder format: 1920x1080 [0:1] yuv420p [hwupload] hwdec 'drmprime' does not report hwframe constraints. Using static metadata. [hwupload] no support for this hw format [hwupload] hardware format not supported [autoconvert] HW-uploading to drm_prime [hwupload] upload yuv420p -> drm_prime[yuv420p] [hwupload] failed to upload frame [vf] Cannot convert decoder/filter output to any format supported by the output. [cplayer] Could not initialize video chain. [vo/dmabuf-wayland/wayland] Deregistering output ``` v4l2request hwdec fails with `Could not create device`, decoder falls back to software, `hwupload` can't convert `yuv420p`→`drm_prime` for the dmabuf-wayland VO, video chain init fails, mpv runs audio-only. The `f6c6e78` screenshot showing real BBB content was captured from screen state that was *not* this mpv invocation — likely a session-restored or stale mpv window from before the test runner pkilled it. The test runner's md5-inequality logic doesn't distinguish "different decoded frame" from "different desktop / different stale window." ## What is still confirmed - Kernel `7.0.0-danctnix1-2-pinetab2-danctnix-besser` running with the 3 RFC patches in `drivers/media/common/videobuf2/`. `videobuf2_dma_contig` module loaded. - Kernel-side stateless decode path is healthy: `ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime ~/fourier-test/bbb_1080p30_h264.mp4 -frames:v 5 -f null -` engages hantro-vpu and outputs `drm_prime(tv, bt709, progressive), 1920x1080`. - `mpv --hwdec=v4l2request --vo=null -v` reaches `Looking at hwdec h264-v4l2request` but fails at `Could not create device`. ## What is NOT validated The vb2_dma_resv RFC v2 patches' effect on the dmabuf-wayland green frame. mpv-fourier 0.41-9 cannot drive the path the patches change. Need either: - An mpv invocation that demonstrably exercises v4l2request → drm_prime → dmabuf-wayland end-to-end, OR - A different reproducer (e.g. firefox-fourier with the same V4L2 stateless path) ## Next: chase the mpv "Could not create device" failure Diagnosis ongoing. Likely candidates: - mpv 0.41 hwdec wrapper regression vs. ffmpeg-v4l2-request-fourier 8.1 - AV_HWDEVICE_TYPE_DRM init failing on `/dev/dri/renderD128` (perms, libdrm version, panfrost) - v4l2_request hwaccel API change in libavcodec 62 Will update with findings.
marfrit reopened this issue 2026-05-09 09:09:12 +00:00
marfrit commented 2026-05-09 10:56:06 +00:00
Author
Owner
Copy Link
Copy Source

iter1 actually confirmed — vb2_dma_resv RFC v2 fixes the green frame

The earlier close was a false positive (test-rig captured stale on-screen content); reopen analysis at #issuecomment-281 was correct. After fixing the actual mpv blocker, the bug is empirically resolved.

What was wrong with the test rig

mpv-fourier 0.41.0-9 could not engage --hwdec=v4l2request zero-copy because mpv 0.41 upstream doesn't wire AV_HWDEVICE_TYPE_V4L2REQUEST through the drmprime VO hwdec. mpv's matcher requires equality on lavc_device; v4l2request decoder needed AV_HWDEVICE_TYPE_V4L2REQUEST but only AV_HWDEVICE_TYPE_DRM was registered → Could not create device → fallback to software decode → silent video-chain failure. Test runner's md5-inequality logic mistook "different desktop content captured by spectacle" for "different decoded frame."

What landed

mpv-fourier 1:0.41.0-10 with two added patches:

  • 0001-meson-add-detection-logic-for-v4l2request-support.patch
  • 0002-vo-hwdec-drmprime-add-separate-hwdecs-for-v4l2reques.patch

Both from Philip Langdale + Jonas Karlman (Aug 2024), originally for DanctNIX's mpv-v4l2request. They add init_v4l2request() to hwdec_drmprime.c that calls av_hwdevice_ctx_create(..., AV_HWDEVICE_TYPE_V4L2REQUEST, ...) and registers a new ra_hwdec_v4l2request driver, plus the meson detection. Built and installed on ohm.

Verification

mpv -v now shows the full zero-copy path:

[cplayer] List of enabled features: ... v4l2request ...
[vo/dmabuf-wayland] Loading hwdec driver 'v4l2request'
[vd] Looking at hwdec h264-v4l2request...
[vd] Trying hardware decoding via h264-v4l2request.
[vd] Pixel formats supported by decoder: vdpau vulkan drm_prime vaapi yuv420p
[vd] Requesting pixfmt 'drm_prime' from decoder.
[vd] Using hardware decoding (v4l2request).
[vd] Decoder format: 1920x1080 [0:1] drm_prime[nv12] bt.709/...
[cplayer] VO: [dmabuf-wayland] 1920x1080 drm_prime[nv12]
[vo/dmabuf-wayland] reconfig to 1920x1080 drm_prime[nv12]

No Could not create device, no hwupload failed, no fallback. The chain is hantro → V4L2 CAPTURE buffer with our dma_resv release fence → VIDIOC_EXPBUF → wl_buffer NV12 → KWin → panfrost EGL_LINUX_DMA_BUF_EXT → Mali sample.

Screenshot result:
Kernel 7.0.0-danctnix1-2-pinetab2-danctnix-besser (vb2_dma_resv RFC v2 patches applied)
mpv mpv-fourier 1:0.41.0-10 (Kwiboo+Langdale v4l2request hwdec wiring)
Test command mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:01:00.0 ~/fourier-test/bbb_1080p30_h264.mp4
Baseline (broken green) md5 c8c8e9b88521a0069f709d483451c3d4
This run md5 3f16fd2471ec0783dfa91040c47c2ad9
Visual full-screen Big Buck Bunny at t=1:00, the iconic close-up of the bunny looking up at sky-blue with green leaves on the right
122,250 distinct colors, entropy 0.605, mean 49261/65535 rich real-frame data

What this empirically validates

  1. v1's buf_queue attach point IS sufficient on RK3566 panfrost zero-copy import — the implicit-sync via dma_resv release fence does land before Mali samples.
  2. The non-IOMMU_CACHE mapping on pfdev->coherent=false is no longer fatal once the fence wait is wired (kernel-level synchronization handles it).
  3. Christian König's "behind a flag for implicit-synced HW" framing is the right pitch for v2.

What v2 still needs to verify

  • The device_run attach-point move (Nicolas Dufresne's finite-time-fence concern) still owes empirical validation. Separate issue at #3.
  • Lockdep cleanliness with dma_fence_begin/end_signalling() annotations.

Closing.

## iter1 actually confirmed — vb2_dma_resv RFC v2 fixes the green frame The earlier close was a false positive (test-rig captured stale on-screen content); reopen analysis at #issuecomment-281 was correct. After fixing the actual mpv blocker, the bug is empirically resolved. ## What was wrong with the test rig mpv-fourier `0.41.0-9` could not engage `--hwdec=v4l2request` zero-copy because mpv 0.41 upstream doesn't wire `AV_HWDEVICE_TYPE_V4L2REQUEST` through the `drmprime` VO hwdec. mpv's matcher requires equality on `lavc_device`; v4l2request decoder needed `AV_HWDEVICE_TYPE_V4L2REQUEST` but only `AV_HWDEVICE_TYPE_DRM` was registered → `Could not create device` → fallback to software decode → silent video-chain failure. Test runner's md5-inequality logic mistook "different desktop content captured by spectacle" for "different decoded frame." ## What landed `mpv-fourier 1:0.41.0-10` with two added patches: - `0001-meson-add-detection-logic-for-v4l2request-support.patch` - `0002-vo-hwdec-drmprime-add-separate-hwdecs-for-v4l2reques.patch` Both from Philip Langdale + Jonas Karlman (Aug 2024), originally for DanctNIX's `mpv-v4l2request`. They add `init_v4l2request()` to `hwdec_drmprime.c` that calls `av_hwdevice_ctx_create(..., AV_HWDEVICE_TYPE_V4L2REQUEST, ...)` and registers a new `ra_hwdec_v4l2request` driver, plus the meson detection. Built and installed on ohm. ## Verification mpv `-v` now shows the full zero-copy path: ``` [cplayer] List of enabled features: ... v4l2request ... [vo/dmabuf-wayland] Loading hwdec driver 'v4l2request' [vd] Looking at hwdec h264-v4l2request... [vd] Trying hardware decoding via h264-v4l2request. [vd] Pixel formats supported by decoder: vdpau vulkan drm_prime vaapi yuv420p [vd] Requesting pixfmt 'drm_prime' from decoder. [vd] Using hardware decoding (v4l2request). [vd] Decoder format: 1920x1080 [0:1] drm_prime[nv12] bt.709/... [cplayer] VO: [dmabuf-wayland] 1920x1080 drm_prime[nv12] [vo/dmabuf-wayland] reconfig to 1920x1080 drm_prime[nv12] ``` No `Could not create device`, no `hwupload failed`, no fallback. The chain is hantro → V4L2 CAPTURE buffer with our dma_resv release fence → VIDIOC_EXPBUF → wl_buffer NV12 → KWin → panfrost EGL_LINUX_DMA_BUF_EXT → Mali sample. **Screenshot result:** | | | |-|-| | Kernel | `7.0.0-danctnix1-2-pinetab2-danctnix-besser` (vb2_dma_resv RFC v2 patches applied) | | mpv | `mpv-fourier 1:0.41.0-10` (Kwiboo+Langdale v4l2request hwdec wiring) | | Test command | `mpv --hwdec=v4l2request --vo=dmabuf-wayland --fullscreen --pause --start=00:01:00.0 ~/fourier-test/bbb_1080p30_h264.mp4` | | Baseline (broken green) md5 | `c8c8e9b88521a0069f709d483451c3d4` | | **This run md5** | **`3f16fd2471ec0783dfa91040c47c2ad9`** | | Visual | full-screen Big Buck Bunny at t=1:00, the iconic close-up of the bunny looking up at sky-blue with green leaves on the right | | 122,250 distinct colors, entropy 0.605, mean 49261/65535 | rich real-frame data | ## What this empirically validates 1. v1's `buf_queue` attach point IS sufficient on RK3566 panfrost zero-copy import — the implicit-sync via `dma_resv` release fence does land before Mali samples. 2. The non-`IOMMU_CACHE` mapping on `pfdev->coherent=false` is no longer fatal once the fence wait is wired (kernel-level synchronization handles it). 3. Christian König's "behind a flag for implicit-synced HW" framing is the right pitch for v2. ## What v2 still needs to verify - The `device_run` attach-point move (Nicolas Dufresne's finite-time-fence concern) still owes empirical validation. Separate issue at #3. - Lockdep cleanliness with `dma_fence_begin/end_signalling()` annotations. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/dmabuf-modifier-triage#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?