Could not queue DRM page flip on screen HDMI

[matzrm]

Hi all,

I have cross-compiled Qt 5.14 on raspberry pi 4 with success, using the brandnew pi4's mkspecs.

The qtbase configure step was ok, it have fouind EGLFS GBM , EGLFS DEVICE and EGLFS X11.

I have added pi to render group, I have created the eglfs.json file with { "device": "/dev/dri/card1" } and I have added the QT_QPA_EGLFS_KMS_CONFIG enviroment variable.

Now when I start my QT\QML application, the app runs but the screen is empty and in console I can read:

Code: Select all

Could not queue DRM page flip on screen HDMI (invalid argument

while if I set, inside eglfs.json the device to /dev/dri/card0, the application crash and in the console I got:

Code: Select all

drmModeGetResources failed (Invalid argument)

Someone can help me?

[6by9]

A couple of guesses.

The GPU on Pi4 is split into 2 - the 3D side, and the rendering side. They are each represented by independent /dev/dri/cardN nodes, and typically the 3D side is card0 whilst rendering is card1. The 3D side doesn't support any form of rendering, therefore will fail any attempt to queue a page flip. Open /dev/dri/card1 instead. (This is what is required to get kmscube running).

DRM also only supports a single client. If X is running then it is the client, and all other attempts to attach as a client will fail.

[matzrm]

After have setted /dev/dri/card1 and then have removed the alpha value from the main object of my qml the application is running correctly.

So the error was caused by:

Code: Select all

color: "transparent"

in the Window object of main.qml.

Thank you

[matzrm]

A couple of guesses.

The GPU on Pi4 is split into 2 - the 3D side, and the rendering side. They are each represented by independent /dev/dri/cardN nodes, and typically the 3D side is card0 whilst rendering is card1. The 3D side doesn't support any form of rendering, therefore will fail any attempt to queue a page flip. Open /dev/dri/card1 instead. (This is what is required to get kmscube running).

DRM also only supports a single client. If X is running then it is the client, and all other attempts to attach as a client will fail.

Is possible that after reboot the card order is inverted? Is possible fix it?

[6by9]

Is possible that after reboot the card order is inverted? Is possible fix it?

Device probe order under Linux isn't guaranteed, but every boot I have seen has had v3d as card0 and vc4 as card1.

If you want to guarantee things, then you enumerate the devices and find the one that has render properties.
Alternatively you use custom udev rules to rename your nodes to a scheme of your choosing.

Generally speaking you'd access DRM/KMS functionality through libdrm which deals with this for you, so I'm not sure why QT is messing about directly. If you check the source code, that is opening /dev/dri/cardN, calling ioctl(DRM_IOCTL_VERSION) and checking for the name.
The underlying driver exposes a driver_features field, which will be missing DRIVER_RENDER if it is the 3D only node. I'm not sure whether that can be queried directly, or whether it is only changing behaviour in drm_dev_init

[matzrm]

Is possible that after reboot the card order is inverted? Is possible fix it?

Device probe order under Linux isn't guaranteed, but every boot I have seen has had v3d as card0 and vc4 as card1.

If you want to guarantee things, then you enumerate the devices and find the one that has render properties.
Alternatively you use custom udev rules to rename your nodes to a scheme of your choosing.

Generally speaking you'd access DRM/KMS functionality through libdrm which deals with this for you, so I'm not sure why QT is messing about directly. If you check the source code, that is opening /dev/dri/cardN, calling ioctl(DRM_IOCTL_VERSION) and checking for the name.
The underlying driver exposes a driver_features field, which will be missing DRIVER_RENDER if it is the 3D only node. I'm not sure whether that can be queried directly, or whether it is only changing behaviour in drm_dev_init

After few attempts I can say that you are right, because Qt can handle this stuff directly so I don't need the file eglfs.json to run my application, and I don't know why some user wrote that this file is needed!

To resume I have crosscompiled Qt 5.12.5 on pi4, with these modules qtdeclarative qtquickcontrols qtquickcontrols2 qtmultimedia qtsvg qtxmlpatterns qtgraphicaleffects qtwebsockets, and I'm running my Qt/QML using GBM on fake kms driver, so without X11.

Thank you

[matzrm]

I have a few questions. Anyone can help me?

Using GBM I can start the application only in fullscreen mode. Is it right?
With the new driver (fkms) alpha channel is not allowed. Is it right?

X11 is the only way to launch more then one Qt\Qml application on screen?

thank you.

[dorche]

After have setted /dev/dri/card1 and then have removed the alpha value from the main object of my qml the application is running correctly.

So the error was caused by:

Code: Select all

color: "transparent"

in the Window object of main.qml.

Thank you

have you find any solution for alpha value?

[jayant_T]

Hi, I just solve this problem.
The eglfs.json is not needed.
just do this:

Code: Select all

export QT_QPA_EGLFS_ALWAYS_SET_MODE="1"

and everything goes well.

But I don't konw why, I hope if someone can tell me.


Remarks:
Raspberry pi4,
EGLFS, EGLFS EGLDevice, EGL GBM EGL x11........yes