Could not find DRM device! Qt v5.15.2 Application

oDinZu commented 3 years ago

Creating a bug report/issue

Required Information

DietPi version |

G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=7
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='not applied'

Distro version | buster 0
Kernel version | Linux oDinPi 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
SBC model | RPi 400 (aarch64)

Additional Information (if applicable)

Software title | Debian Direct Rendering Manager (DRM)
Was the software title installed freshly or updated/migrated? Fresh

Steps to reproduce

... Compile Qt application on RPI 400
... Launch fresh built binary

Expected behaviour

...Application runs without DRM error

Actual behaviour

- Could not find DRM device!
Aborted

Extra details

I configured my Qt application, make the application and make install the Qt application.

I am wondering specifically if the DRM error is associated with this Debian in particular? I found this thread from 2020 and wondering if it applies to debian diet-pi?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968181

MichaIng commented 3 years ago

Many thanks for your report.

Are the DRM devices really not present?

ls -l /dev/dri

If so, is the KMS of fMKS driver enabled?

grep 'vc4-.*kms-v3d' /boot/config.txt

If not, please enable it. This can be done via dietpi-config > "Display Options" > "Resolution" (reminds me that we need to move it out there...), or by manually adding:

dtoverlay=vc4-fkms-v3d

for the fake KMS driver, or

dtoverlay=vc4-kms-v3d

for the full KMS driver to /boot/config.txt.

Hmm, I wanted to add an offical RPi docs link for this, but sadly the new documentation has it scattered and no section which explains the three graphics drivers explicitly 😢: https://www.raspberrypi.com/documentation/

oDinZu commented 3 years ago

Awesome :birthday: :+1: . Thanks for your speedy response.

ls -l /dev/dri ls: cannot access '/dev/dri': No such file or directory

grep 'vc4-.*kms-v3d' /boot/config.txt a cricket playing his fiddle at night

On going to dietpi-config >> display >> resolution, I see I didn't have any driver loaded for some odd reason. It said Current resolution: 0.

I am testing the vc4-kms-v3d-pi4 now; rebooting...

Then, I have to rebuild the qt app again.

MichaIng commented 3 years ago

Not uncommon. By default no KMS driver is enabled on DietPi, hence the legacy framebuffer based driver is used for GUI. But some applications obviously require DRM, hence a KMS driver enabled.

Resolution 0 looks odd, probably this is shown when none has been explicitly selected. We should then show auto, as this is what is effectively done, using the native screen resolution minus overscan, which is usually perfectly fine. When starting any GUI application via DRM/KMS, this framebuffer resolution isn't effective anyway, but only for the bare console.

I guess you don't need to rebuild the app. If the required development headers were installed, it compiles regardless whether the DRM/KMS is enabled or not. But if it still does not work, then a rebuild is definitely worth an attempt.

oDinZu commented 3 years ago

I guess you don't need to rebuild the app. If the required development headers were installed, it compiles regardless whether the DRM/KMS is enabled or not. But if it still does not work, then a rebuild is definitely worth an attempt.

I tested the original bin file ./app and didn't have the DRM error. Although, sudo timer tricked me on Halloween and built the binaries with sudo, therfore, I was receiving permission for HDMI.

gdb ./app

Failed to move cursor on screen HDMI1: -13
Could not queue DRM page flip on screen HDMI1 (Permission denied)
Could not set DRM mode for screen HDMI1 (Permission denied)

I need to sudo visudo

Defaults env_reset, timestamp_timeout=00

If it aids in the troubleshooting process, this is my Qt configuration I am using for RPI 400.

PKG_CONFIG_LIBDIR=/usr/lib/aarch64-linux-gnu/pkgconfig/:/usr/share/pkgconfig/ \
../qt5-sources/qt-everywhere-src-5.15.2/configure -platform linux-rpi64-vc4-g++ \
-v \
-opengl es2 -eglfs \
-no-gtk \
-opensource -confirm-license -release \
-reduce-exports \
-force-pkg-config \
-nomake examples -no-compile-examples -nomake tests \
-skip qtwayland \
-skip qtwebengine \
-no-feature-geoservices_mapboxgl \
-qt-pcre \
-no-pch \
-ssl \
-evdev \
-system-freetype \
-fontconfig \
-glib \
-prefix /opt/Qt/5.15.2 \
-qpa eglfs

ldd ./app

linux-vdso.so.1 (0x0000007fab3e6000)
    libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fa6e7e000)
    libQt5Widgets.so.5 => /opt/Qt/5.15.2/lib/libQt5Widgets.so.5 (0x0000007fa67fa000)
    libQt5Gui.so.5 => /opt/Qt/5.15.2/lib/libQt5Gui.so.5 (0x0000007fa61c7000)
    libQt5WebSockets.so.5 => /opt/Qt/5.15.2/lib/libQt5WebSockets.so.5 (0x0000007fa6182000)
    libQt5Network.so.5 => /opt/Qt/5.15.2/lib/libQt5Network.so.5 (0x0000007fa5fac000)
    libQt5Core.so.5 => /opt/Qt/5.15.2/lib/libQt5Core.so.5 (0x0000007fa59af000)
    libGLESv2.so.2 => /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 (0x0000007fa597a000)
    libEGL.so.1 => /usr/lib/aarch64-linux-gnu/libEGL.so.1 (0x0000007fa5956000)
    libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa5927000)
    libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fa579c000)
    libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fa56df000)
    libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fa56bb000)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa5549000)
    /lib/ld-linux-aarch64.so.1 (0x0000007fab3b8000)
    libpng16.so.16 => /usr/lib/aarch64-linux-gnu/libpng16.so.16 (0x0000007fa5504000)
    libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007fa54d7000)
    libicui18n.so.63 => /usr/lib/aarch64-linux-gnu/libicui18n.so.63 (0x0000007fa5204000)
    libicuuc.so.63 => /usr/lib/aarch64-linux-gnu/libicuuc.so.63 (0x0000007fa5029000)
    libicudata.so.63 => /usr/lib/aarch64-linux-gnu/libicudata.so.63 (0x0000007fa362b000)
    libzstd.so.1 => /usr/lib/aarch64-linux-gnu/libzstd.so.1 (0x0000007fa3594000)
    libgthread-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libgthread-2.0.so.0 (0x0000007fa3582000)
    libglib-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000007fa3450000)
    libGLdispatch.so.0 => /usr/lib/aarch64-linux-gnu/libGLdispatch.so.0 (0x0000007fa32c5000)
    libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000007fa3252000)

oDinZu commented 3 years ago

Not uncommon. By default no KMS driver is enabled on DietPi, hence the legacy framebuffer based driver is used for GUI. But some applications obviously require DRM, hence a KMS driver enabled.

According to @oniongarlic, KMS is required for RPI 4.

"Note: For a Qt 5 that will be run on a Raspberry Pi 4 you must use KMS, Broadcom EGL is not supported on that model and never will. Make sure you have installed the packages: libgles2-mesa-dev libgbm-dev"

Further investigation, it seems, they are focused on using Vulkan :vulcan_salute: https://www.raspberrypi.com/news/vulkan-update-merged-to-mesa/

MichaIng commented 3 years ago

This should be true for all RPi models, good that it is clear then.

Jep, initial Vulkan support will be part of Mesa 21. Bullseye however ships only Mesa 20. Mesa 21 has been merged to Bookworm already: https://packages.debian.org/search?keywords=libegl1-mesa With some luck, it will be either available via backports for Bullseye, and/or the RPi repo maintainers add a build to the RPi repository: https://archive.raspberrypi.org/debian/pool/main/m/mesa/?C=M;O=D

oDinZu commented 3 years ago

Ok, after rebuilding and everything else, all I needed to do is use -platform xcb (X11) after enabling https://github.com/MichaIng/DietPi/issues/4916#issuecomment-955786469

./app -platform xcb

I am super new to this whole process, including Qt. It is a super complex piece of software.

At first, without adding platform specific options, it was providing lots of errors. I shouldn't have to add -platform xcb when running the binary...then again, I haven't created a app.deb for it.

@MichaIng Thank You!

MichaIng commented 3 years ago

Okay great. I'm also no expert in this, but XCB is a generally optional platform plugin/X11 abstraction, through on Linux seems to be required now: https://doc.qt.io/qt-5/linux-requirements.html Probably there is a build option to force XCB, respectively disable direct/low-level alternatives in the first place.

oniongarlic commented 3 years ago

Ok, after rebuilding and everything else, all I needed to do is use -platform xcb (X11) after enabling #4916 (comment)

./app -platform xcb

My Qt instructions are using "-qpa eglfs" to set the default platform to eglfs as I prefer to run without X11. Just change (or remove) that option to change the default. I haven't yet tested Vulkan on Qt 5 but on 6 it works nicely.

oDinZu commented 3 years ago

@oniongarlic I thought my RPi 4 made use of eglfs as default. I didn't know how to verify or check for this.

I am still unsure why I had to use X11 (xcb) on my RPi 400.

I updated my configuration file with:

-bundled-xcb-xinput -qpa xcb

I'm compiling now.; testing later; ultimately, I want my binaries from Qt to run on v8 ARM.

P.S> @oniongarlic Do I need to make and make install every configuration change? It currently takes about 8-10hrs on my RPi 400 with -j3 enabled to compile 5.15.3. I would like to build for v6 & v7 ARMs.

I could probably cross-compile on my amd64, but this opens other ldd problems. I am very new to the Qt process and cross-compiling makes things more complex.

I am use to cross-compiling with docker-engine on amd64 and moving files manually over to different architecture.

Update:

I noticed make -j 3 (with a space) actually works. I compiled twice on RPi 4 for 10hrs, tonight i used -j (space) 3 and it completed half the time.

oDinZu commented 3 years ago

My compiled C++ code with Qt5.5.15.2 compiled and I didn't need to add ./app -platform xcb to run the application, plus it compiled x2 faster with -j (space) 3 on RPi v4.

MichaIng commented 3 years ago

make -j3 and make -j 3 should be 100% equivalent 🤔. Did you have a look into htop or so during compilation to see whether 3 build processes are running or not? However, if -j 3 works for you, no need to debug 😄.

MichaIng commented 3 years ago

I'll mark this issue as closed. Feel free to reopen if questions remain.

MichaIng / DietPi