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 vc4 and a v3d kernel module are loaded to provide the DRM/KMS interface
The VC4 interface is via /dev/drm/card1. The V3D interface is via /dev/drm/card0
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_CONFIG might 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.
One more thing to add, the account set as responsible is a team account so it means it has several members like Paul. The fact it is shown as not active is just related to the fact that it's not a physical person.
There are several others like that :-)
I determined that I am not missing any frames. So I must be doing something funky with the data, or the data I am getting is funky. I did determine that my function is being called 170+ times per second. So not super fast.
@J-Hilk Thanks for the info.
A forum for independent Developers and freelancers
A difficult case. There are software for monitoring and sniffer. I know exactly what https://com-port-monitoring.com Pro version will handle this. Alas, software is not free, but it will definitely be able to open a COM port that is already connected. And I agree with the previous speaker in USB-Serial, you're even more limited.
the tool will be presented at the Requirements Engineering Conference 2019 in Korea (http://re19.ajou.ac.kr/).
For this conference we created a video showing the use cases of our tool:
If you got curious, try the tool out for yourself :)