Feature Request: Enable Writeback or Scanout Access on Raspberry Pi 5 (VC6)

Hi LibreELEC team,

first of all, thank you for your fantastic work – LibreELEC runs great on the Raspberry Pi 5!

I'm currently working on a solution to capture the screen output (HDMI) for Ambilight-style applications like Hyperion. On the Pi 4, this was easily done using DRM framebuffer access.

However, on the Pi 5 with the new VC6 graphics stack, it seems that access is blocked or restricted.

System:

• LibreELEC 12.0.2 (aarch64)
• Raspberry Pi 5
• Live TV via TVHeadend (e.g. ARD HD)
• HDMI output: 1920×1080p @ 50Hz

What works:

• GUI layers (e.g. Kodi menu) can be accessed via DRM plane → screenshots possible
• Kodi JSON-RPC (GUI.Screenshot) works, but only captures GUI

What does not work:

• During fullscreen video (e.g. ARD HD), all DRM planes have fb_id = 0
• No writeback connector appears in modetest
• drmModeGetFB() fails with EINVAL or EOPNOTSUPP
• EGL/GBM offscreen capture fails (eglCreatePbufferSurface)

Feature request:
Would it be possible to:

• expose a DRM writeback connector for the Pi 5 in future versions?
• or alternatively allow scanout framebuffer access (e.g. via plane export, dumb clone, or V4L2)?

This would allow full-screen screen grabbing on the Pi 5 just like we had on the Pi 4, and restore compatibility for Hyperion and similar tools.

Happy to provide test code, logs or example screenshots if useful.

Thanks again for your great work and support!

Best regards,
Henry

Update – test results based on kernel-level guidance from 6by9:

We’ve confirmed that all user-facing DRM APIs are unable to access the scanout framebuffer on Pi 5 / VC6.

Even direct re-creation with `drmModeAddFB2` using known YU12 parameters fails with “operation not supported”.

Conclusion: Only Kodi could provide framebuffer-based rendering again – or Pi firmware would need to support writeback in the future.

Thanks to the team for the open technical discussions!

✅ Final Project Status (May 2025)

We've now tested all technically available methods for accessing the video framebuffer on a Raspberry Pi 5 (VC6) running LibreELEC 12.80.2 (Kernel 6.6), including:

- Classic DRM access via `drmModeGetPlane` and `drmModeGetFB2`
- Memory export via `drmPrimeHandleToFD()` and `mmap()`
- Custom grabber tools (`planegrab`, `rendergrab`, `fb2-racecheck`)
- The `kmsgrab` tool provided by 6by9 (which supports multi-plane formats)

🔍 Result:
While the `fb_id` of the video plane (YU12 format) is visible and valid,
**all attempts to map the framebuffer memory fail with `EINVAL` or result in zero-filled output** –
even when using `kmsgrab`, which internally uses the correct DRM and Prime APIs.

📦 The `.raw` dump files generated by `kmsgrab` are structurally correct,
but contain no usable image data — likely due to **driver- or memory-export restrictions in the VC6 stack.**

---

🧠 Conclusion:

The current driver and kernel architecture **do not allow userland tools to access the scanout image from hardware video overlays** on Raspberry Pi 5 (VC6),
even when all APIs are correctly used.

This matches the confirmation by 6by9 that **this is not a bug**, but expected system design:
the overlay content is not exported for direct access.

---

🧭 What's next?

We will **pause further testing until a newer kernel (e.g. 6.8+) explicitly introduces framebuffer export improvements, writeback support, or enhanced plane access.**

At that point, we will re-evaluate and continue our efforts.

Thanks to everyone who helped clarify the details – especially @6by9 and the LibreELEC and Kodi devs.

Henry

chewitt
Thanks for all !
For the time being, the is no chance for a grabber on pi5 due to restricted (drmModeGetPlane + drmModeGetFB) and other hidden features in the PI5 kernel.
The only solution is an external HDMI grabber device, as you already mentioned.

I think we can close at this point.

Regards
Henry