Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
DRM/KMS configuration for Raspberry Pi 4
fhunleth last edited by
I'm trying to get Qt running on a Raspberry Pi 4 fullscreen and without Raspbian - specifically the 3D accelerated parts. I'm using Buildroot, but have matched my Linux kernel configuration, mesa3d versions, etc. to ones running on Raspbian.
Here's my current understanding:
- Upstream is moving from the proprietary Broadcom interface to DRM/KMS
- Raspbian enables the "firmware" KMS device tree overlay (
vc4-fkms-v3d) for the Raspberry Pi 4, so this is what I'm doing to
- In this configuration, a
v3dkernel module are loaded to provide the DRM/KMS interface
- The VC4 interface is via
/dev/drm/card1. The V3D interface is via
- All drawing commands go to V3D (aka card0)
- All screen resolution and configuration commands go to VC4 (aka card1)
Qt's automatic detection of which card to use doesn't work. For me, it has been picking card1 so the screen resolution gets set and I get a hardware cursor that seems to work. However, graphics drawing requests fail. If I force card0, then my test program fails quickly when Qt tries to get the screen resolution.
It feels like
QT_QPA_EGLFS_KMS_CONFIGmight be useful, but I'm not sure how to configure some commands going to card0 and some going to card1.
Is this possible?
Also, I'm using Qt 5.13.0. I didn't see anything recent that might address that, but if upgrading or pulling in a patch, I'll certainly try.
maxwell31 last edited by
Does this mean I should not link against the libs in /opt/vc (the broadcom libraries)? If not, what do I need to do (see https://forum.qt.io/topic/108730/running-a-qtquick-app-on-raspberrypi-4-problem-rendering-app-to-screen/3 )
Regarding your eglfs question: Maybe try eglfs.json like suggested here