I reported this issue a few years ago: https://bugreports.qt.io/browse/QTBUG-92059 , but there has been no substantial progress. Can this issue be pushed forward again? Even though many years have passed, the situation has not improved. Most Linux distributions are still facing this dilemma. For example, Debian: https://lists.debian.org/debian-devel/2018/11/msg00457.html ― in order to work around this issue, Debian provides two sets of Qt deb packages: one built with desktop OpenGL, and another with OpenGL ES. This is rather ugly. If Qt allowed choosing between OpenGL ES and desktop OpenGL dynamically at runtime, the problem would be elegantly solved.
Q: Why can't we just decide at compile time that Qt on a certain architecture (e.g., arm64 or RISC-V) should always use OpenGL ES? A: Because some Linux distributions need to support a wide variety of hardware. Take arm64 (and similarly RISC-V) as an example: Some arm64 devices only support GLES (such as SoCs with Mali GPUs), while other arm64 devices are more like x86 platforms ― they are used in laptops, desktop PCs, and servers, support PCIE, and can even use AMD/Nvidia discrete GPUs. For such devices, it makes no sense to default to GLES. Q: Why not just provide two builds of Qt like Debian does ― one for GLES, one for desktop OpenGL? A: This makes dependency management extremely difficult and is only a last-resort workaround. Within the Qt community, I hope we can discuss a better solution together. In fact, I noticed that Debian no longer provides dual Qt builds in Qt6, though I don’t know the reason.
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
