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
✅ 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
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!
chewitt
Thanks, I give it a try.
Thanks again
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:
--- DRM Test Protocol: drm-vc6-grabber (C) on Raspberry Pi 5 ---
📦 System:
- Device: Raspberry Pi 5
- LibreELEC Image: LibreELEC-RPi5.aarch64-12.80.2 (by @chewitt)
- Kernel: default from image
- Kodi: active (idle menu & live TV tested)
🧰 Grabber Tool:
- Name: drmgrab-vc6
- Language: C (no Rust dependencies)
- Method: classic DRM ioctl calls (xf86drm / drmMode*)
- Build: cross-compiled on Debian 12 using aarch64-linux-gnu-gcc
🧪 Execution:
- Binary copied to: /storage/drmgrab-vc6
- Run manually via SSH: ./drmgrab-vc6
🎯 Result:
- drmModeGetResources() → fails immediately
- Error: "❌ drmModeGetResources: Operation not supported"
- Exit code: 1
📌 Observation:
- Happens both in Kodi GUI (idle) and during fullscreen video playback
- No connector/CRTC information available → no framebuffer access possible
- Tool works correctly on Pi 4 (same source)
✅ Conclusion:
- `drmModeGetResources()` is blocked on VC6 under LibreELEC
- Even read-only DRM access is suppressedThanks 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
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:
What works:
What does not work:
Feature request:
Would it be possible to:
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
chewitt
Thanks a lot, I did.
I hope to make Hyperion work again on the Raspberry 5.
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.
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:
Since the move to KMS + VC6 on Raspberry Pi 5, it is no longer possible to access the visible framebuffer using traditional means like:
Errors such as EOPNOTSUPP are returned for plane/resource queries, breaking:
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.
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
