[Feature Request] Expose current scanout framebuffer for screenshot/grabber tools on Raspberry Pi 5 (VC6 DRM/KMS)

[cpthein]

Describe the bug

Summary

This is a feature request for Raspberry Pi 5 devices using the VC6 DRM/KMS driver.

We are developing screenshot and grabbing tools (e.g. for Hyperion Ambilight) that rely on reading the current scanout framebuffer for real-time image analysis. This has previously been possible using DRM/KMS APIs on earlier platforms, but appears to be restricted on the Raspberry Pi 5 with VC6.

Problem Description

On the Raspberry Pi 5 (LibreELEC 12, Kernel 6.6.x, VC6 driver with KMS), attempts to access the active plane's framebuffer using DRM APIs such as drmModeGetPlane() or drmModeMapDumb() fail with:

Steps to reproduce the behaviour

This prevents tools like Hyperion or custom grabbers from accessing the screen content, which was previously possible on Pi 4 or other DRM platforms.

Suggested Solution

We propose introducing a mechanism that allows tools to access or export the scanout framebuffer. Possible options include:

• Exposing a device like /dev/scanout-export that exports the current buffer as a DMA-BUF
• Allowing read access to the active scanout framebuffer via drmModeMapDumb or similar
• Adding an ioctl to request the framebuffer handle (with appropriate restrictions)
• Providing an official method to clone the scanout plane for read-only access

Use Case

• Screenshot generation (e.g. for remote display tools)
• Ambilight-style real-time processing (e.g. Hyperion)
• Visual monitoring/debugging of rendered output

These tools are widely used in home automation and multimedia contexts and would greatly benefit from access to the visible framebuffer.

Additional Notes

• We understand that security and memory coherence are important concerns.
• Access could be restricted to CAP_SYS_ADMIN or to whitelisted tools.
• We are open to contributing or testing kernel patches if guidance is provided.

System Info

• Platform: Raspberry Pi 5
• OS: LibreELEC 12.0.2 (64-bit)
• Kernel: Linux 6.6.x
• Graphics: KMS, VC6

Device (s)

Raspberry Pi 5

System

• Platform: Raspberry Pi 5
• OS: LibreELEC 12.0.2 (64-bit)
• Kernel: Linux 6.6.x
• Graphics: KMS, VC6

Logs

No response

Additional context

No response

[dividuum]

Your error message is missing, so I'm not sure what problem you run into, but I assume you already tried tools like kmsgrab.

I'm not related to the Pi people but have been closely following the development and transition from legacy stack to KMS/DRM and I would be very surprised if this would ever get merged: One of the big reasons to move to KMS/DRM was to be close to upstream. Your request would add a special "backdoor" to DRM which I predict won't be happening.

Another issue is that while probably true in most cases, it is easily possible there isn't only a single framebuffer/plane on screen: multiple planes can be composed and overlay in various ways (like with added transparency), so just grabbing a single framebuffer isn't enough. And of course there can be multiple CRTCs.

The proper way to solve this is by cooperating with a compositor which can duplicate output to an RGBA framebuffer via the Writeback connector. When done properly you get exactly what's on the display and I think I got it to work at 60Hz for FullHD. Unfortunately there isn't an easy way to add this to program running as DRM master.

[siddhudhusid]

Hi everyone,
I am new to this anyone please guide me how to join community and how to contribute,

Sorry to comment this but I don’t how join.

Thanks

[cpthein]

Hi @dividuum,

thank you very much for your detailed and thoughtful reply – it’s exactly the kind of technical background I was hoping for.

You're absolutely right: I hadn’t considered the complexity of multiple planes and the architectural consequences of exposing scanout buffers directly. I fully understand that such a feature would break the upstream conformity that KMS/DRM is aiming for, and I appreciate your clear explanation of why this isn’t likely to happen.

Your suggestion to use the Writeback connector makes perfect sense. I wasn’t aware it could be used this way with real-time grabbers, especially with such performance (FullHD @ 60Hz sounds great!).

I’ll definitely look into how to set this up properly, and maybe we can build a dedicated capture path around it that plays nicely with Hyperion or similar tools.

Thanks again for your insights – much appreciated!

Best regards,
cpthein

[6by9]

This has previously been possible using DRM/KMS APIs on earlier platforms, but appears to be restricted on the Raspberry Pi 5 with VC6.

The DRM/KMS API that is implemented is near identical across Pi0-5 as they all go through the vc4 driver.
Can you give more details of exactly which API calls you believe have changed on Pi5?

Do note that DSI, DPI, and VEC outputs on Pi5 have moved from being part of vc4 to independent DRM devices. If you're trying to scrape those, then you'll need to be finding the right DRM instance.

[cpthein]

Thanks for the response, 6by9!

We're working on a screenshot grabber tool for Hyperion (Ambilight), which previously used drmModeAddFB2, drmModeGetPlaneResources, and drmModeGetPlane to access the current scanout framebuffer on Pi4 and earlier. These calls return valid results on Pi4, but fail with EOPNOTSUPP on Pi5 (LibreELEC 12.0.2, Kernel 6.6.x, using /dev/dri/card0 and HDMI-A-1 as the active connector).

Specifically:

• drmModeAddFB2 fails when trying to rebind the scanout framebuffer (for capture).
• drmModeGetPlaneResources works, but drmModeGetPlane(plane_id) gives a framebuffer ID of 0.
• drmModeGetFB on that ID fails, as expected.

We are not using DSI/DPI/VEC, only HDMI on card0.

Could it be that the planes (CRTC/primary) are protected or unexported on Pi5 (VC6) in the current firmware/kernel? Is there any path forward for clean read access to the scanout image (e.g. via writeback or dumb buffer clone)?

Ultimately, our goal is to restore working screenshot support for tools like Hyperion.ng on the Pi5, ideally through clean DRM/KMS interfaces (e.g., plane readout, writeback, or an exported framebuffer).

Thanks!

[6by9]

(LibreELEC 12.0.2, Kernel 6.6.x, using /dev/dri/card0 and HDMI-A-1 as the active connector).

The ordering of DRM devices is not guaranteed, and varies based on probe order.
You have both vc4 and v3d as DRM devices loading on both Pi4 and Pi5. Assuming that vc4 will always load as /dev/dri/card0 is likely to fail on either.

Iterate DRM devices to find one with exposed connectors, or you can call drmOpen with a module or device name (you probably want module to be vc4).

[cpthein]

Thanks a lot, 6by9 – that's extremely helpful!

We were indeed assuming that /dev/dri/card0 would always be the vc4 node – and that was clearly the wrong assumption.

We'll now update our code to either use drmOpen("vc4", NULL) or iterate the DRM devices to find the one with the active HDMI connector.

Thanks again for the clarification and quick response!