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!

    The GBM/V4L2 video pipeline is completely different to the previous method used with RPi boards so the approach also needs to be different and zero-copy rendering brings inherent problems for the ambilight use-case. The same issue also exists with Allwinner, Amlogic, and Rockchip devices that use the same DRM framework in the same way.

    lrusak did some initial work on screenshot support a couple of years ago: https://github.com/xbmc/xbmc/pull/18741 but IIRC this had a problem level of impact on rendering and the effort stalled. It might be acceptable to resurrenct that for the kind of ad-hoc screenshot usage but IIRC it's the wrong approach for 60fps video.

    Our advice is (and has been since LE10) that people wanting to use Ambilight should use an HDMI grabber device. It's not as cheap as past methods, but it's simple and works everywhere.

    ✅ 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