Feature Request: DRM/Framebuffer Access for Screenshot/Grabber Tools on Raspberry Pi 5 (LibreELEC 12 / VC6)

    Hello LibreELEC developers,

    I'd like to suggest a feature that could benefit many community projects, especially those related to Hyperion (Ambilight) and screenshot-based display analysis.

    Goal:

    Enable access to the current scanout framebuffer on Raspberry Pi 5 with VC6/KMS driver – for use in screenshot or grabber tools – by optionally providing:

    • a kernel module
    • a char device (/dev/scanout-export)
    • a DMA-Buf export point
    • or an alternative interface (e.g. DRM plane clone, gbm_bo_export, etc.)

    Background:

    Since the move to KMS + VC6 on Raspberry Pi 5, it is no longer possible to access the visible framebuffer using traditional means like:

    • drmModeGetResources()
    • drmModeGetPlane()
    • gbm_bo_map()

    Errors such as EOPNOTSUPP are returned for plane/resource queries, breaking:

    • Hyperion DRM grabbers (VC4 still worked)
    • DRM-based screenshot tools
    • Live color analysis (e.g. ambient lighting, automation)

    Why this matters:

    Hyperion and other tools rely on capturing the live screen content for Ambilight effects or HDMI-based automation.

    Under LibreELEC 12 (aarch64, VC6), this capture is currently not possible at all.

    ✅ Proposal:

    • Provide an optional kernel module or grabber interface
    • Make the current scanout framebuffer accessible through DMA-Buf export
    • Alternatively, expose a linear, readable framebuffer via a lightweight device (e.g. /dev/scanout-dma)

    I'm happy to help testing this or discussing viable implementation options.
    Even partial access or a Kodi-based workaround could unblock community projects.

    Thank you for considering –
    Greetings from the North,
    CptHenry

    I'd suggest you submit the idea to the Raspberry Pi kernel developers via their GitHub repo as this is not something that will be developed by LE staff.

    I'm forgetting that this exists: https://github.com/rudihorn/drm-vc4-grabber

    If you want to experiment, the /usr/bin/drm-vc4-grabber binary is embedded in this image:

    https://chewitt.libreelec.tv/testing/LibreE…-12.80.2.img.gz (and the .tar)

    Note that I've only compiled the package, I have no means of testing it. The 'drm-capture' service should run on boot.

    Package changes are here: https://github.com/chewitt/LibreELEC.tv/commits/rpi-13.0

    If it works well it could be repackaged as an add-on, although an in-kernel solution would still be nicer.

    Thanks a lot, chewitt – this is incredibly helpful!

    I’ll test the provided image on my Pi 5 and report back. Very cool to see `drm-vc4-grabber` already integrated with a service – that’s exactly the kind of approach we’ve been working toward.

    I’ll keep you updated with results and observations.

    Much appreciated!
    Henry

    Thanks again

    chewitt

    for your earlier input and the test image with `drm-vc4-grabber`.

    We've now completed extensive testing on a Pi 5 using your image `LibreELEC-RPi5.aarch64-12.80.2`, and a custom-built DRM test tool written in C.

    Unfortunately, even the most basic DRM call — `drmModeGetResources()` — fails on `/dev/dri/card0` with:

    ❌ drmModeGetResources: Operation not supported

    This error (EOPNOTSUPP) occurs consistently, regardless of whether Kodi is idle (GUI visible) or fullscreen video (TVHeadend live stream) is running. No connector or resource enumeration is possible at all.

    To confirm this is not a tool issue, we built both Rust and C versions, cross-compiled on Debian 12, and tested cleanly on the Pi 5 with the default LibreELEC kernel and your custom image.

    ---

    ### What we're asking:

    Would it be possible to enable support for at least `drmModeGetResources()` on `/dev/dri/card0`?

    Ideally, either:
    - Allow basic scanout access for screenshot tools (like Hyperion, or framebuffer readers)
    - Or enable the DRM writeback connector (if supported on VC6)

    We understand that security and rendering separation are design decisions on VC6, but right now it's blocking even read-only diagnostics that worked perfectly on the Pi 4.

    ---

    Happy to share test logs, source code, or help with packaging/debugging if needed.

    Thanks again for your time and continued support!

    Henry


    Here’s the test log from the Pi 5 run: