Arch Linux

citrus

Member

Registered: 2018-07-04

Posts: 13

Qt6 platform plugins

Hi, I am trying to get my Qt6 GUI program to support OpenGL rendering. Unfortunately, it is currently crashing with the following message: "qt.qpa.wayland: EGL not available".

The error itself does not really bother me too much, because it is probably only a question of installing the right dependencies on my system. What I would like to discuss here instead is the way Qt6 platform plugins work in general, since I would eventually like to distribute my program across many different environments (some of which may support EGL, while others may not) and I would like to make it as robust as possible.

I am aware that Qt6 has various platform plugins that encapsulate communication with window servers, for instance my app claims to support the following plugins: "offscreen, vnc, wayland, linuxfb, wayland-egl, vkkhrdisplay, xcb, eglfs, minimal, minimalegl". That being said, I always thought that the reason for having multiple such plugins is that if one of them does not work, Qt6 simply selects another viable alternative and tries again until all options are exhausted. For instance, if "wayland-egl" fails to initialize, Qt6 should by smart enough to try "wayland", then perhaps "xcb", and crash the program if and only if neither of these options work. What appears to be happening instead is that Qt6 only selects one plugin, here "wayland-egl", and crashes if it fails to initialize. This is undesirable for distribution.

I tried to find some information on this in Qt6 documentation. Unfortunately there are not too many resources on this topic, which I could study. Would anybody happen to know if there is a way to implement the cascade behavior I described above?

Lone_Wolf

Forum Moderator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 11,961

Re: Qt6 platform plugins

Selecting a QPA plugin

Qt will select a default QPA plugin, depending on the platform. The QT_QPA_PLATFORM environment variable and the -platform command line argument allow you to override this default. See QGuiApplication for more details.

OpenGL should work on the majority of those platforms, why does your app care which platform is used ?

you have looked at https://doc.qt.io/qt-6/qtopengl-index.html ?

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

(A works at time B)  && (time C > time B ) ≠  (A works at time C)

citrus

Member

Registered: 2018-07-04

Posts: 13

Re: Qt6 platform plugins

OpenGL should work on the majority of those platforms, why does your app care which platform is used ?

I understand that the whole point of having QPA is to create an opaque abstraction layer, so that my app does not (and should not have to) care about this. In my case, however, I do have to pay some attention to it since in addition to distributing source code and regular packages (dpkg, rpm), I also distribute my app in the form of self-extracting AppImages, which achieve a reasonable degree of portability by bundling all dependencies inside.

When producing these binaries, all dependencies have to be identified by a recursive walk with ldd. Using strace I just found that the reason for the EGL-related crash is that the wayland-egl platform plugin depends on libEGL_mesa.so.0 in a non-standard way. It does not specify dynamic linkage relationship, so that ldd does not pick it up, and instead looks for the right file by itself. If the file in question is located, it is dynamically loaded at runtime, otherwise EGL initialization fails, triggering a failure of wayland-egl that I observed. Please note that I have observed a similar non-standard dependency for instance in GDK pixbuf image loaders. The issue here is that Qt6 for some reason automatically selects wayland-egl even though the module subsequently fails to initialize. Ideally, I would have expected Qt6 not to have selected this option unless plugin initialization was guaranteed (or at least likely) to succeed.

you have looked at https://doc.qt.io/qt-6/qtopengl-index.html ?

Yes, thank you. Even though this documentation page is not as detailed as I would have wished, it provided some insight into how OpenGL works under Qt.

I suppose that when I created this thread, I wanted to discuss QPA in general rather than OpenGL in particular. I did not understand why Qt offers multiple facilities to connect to the window server, but then puts all its eggs into one basket, and bails out on the first failure.