#1035985 Built without GLESv2 support causing errors on machines only supporting GLES

Package:
qt6-base
Source:
qt6-base
Submitter:
Erik Inkinen
Date:
2025-01-18 00:54:01 UTC
Severity:
normal
#1035985#5
Date:
2023-05-12 08:45:56 UTC
From:
To:
Qt5 packages had separate GLES versions packaged in Debian, but on Qt6
the rendering backend was revamped by Qt so that the same binaries can
support desktop GL and GLES.

For some reason, the current Debian packaging does not include libGLES
development headers in Build-Depends. When configuring the build, Qt
will not be able to enable GLESv2 support. These packages then cannot be
used to render anything on devices that do not support desktop GL, but
have GLES support.

I have confirmed that building with GLES packages indeed fixes the errors.
#1035985#12
Date:
2023-05-30 20:02:00 UTC
From:
To:
Dear Maintainer,

please consider bumping the severity level of #1035985, as it makes
Debian unable to use qt on the many embedded platforms, and the next
stable will be affected by this for a long time. Is it possible to
include the `QT_FEATURE_opengles2` flag before the release? I'm
willingly to send a patch if needed.

Regards
#1035985#17
Date:
2023-06-05 01:41:46 UTC
From:
To:
Hi!

I am afraid it was discovered too late in the release process. My plan
is to test it as soon as Bookworm is released and hopefully get a
stable pu update. But I can't promise anything.

Bumping the severity for a feature not discovered in time is a non-go.
#1035985#22
Date:
2023-06-05 23:31:21 UTC
From:
To:
Hi Erik, Leonardo

On Sun, 4 Jun 2023 22:41:46 -0300 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> wrote:
[snip]

[0] <https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/blob/master/debian/control#L21>

Moreover, if you grep for "gles" in the build log [1] you will see that both libgles1 and libgles2 are present.

[1] <https://buildd.debian.org/status/fetch.php?pkg=qt6-base&arch=amd64&ver=6.4.2%2Bdfsg-10&stamp=1685266695&raw=0>

Or even:

```
-- Performing Test HAVE_GLESv2
-- Performing Test HAVE_GLESv2 - Success
-- Found GLESv2: /usr/include 
```

If I force FEATURE_opengles2=ON I get:

```
CMake Error at cmake/QtBuildInformation.cmake:490 (message):
  Feature "opengles2": Forcing to "ON" breaks its condition:

      NOT WIN32 AND NOT WATCHOS AND NOT QT_FEATURE_opengl_desktop AND GLESv2_FOUND

  Condition values dump:

      WIN32 = ""
      WATCHOS = "0"
      QT_FEATURE_opengl_desktop = "ON"
      GLESv2_FOUND = "TRUE"

Call Stack (most recent call first):
  cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
  cmake/QtFeature.cmake:403 (qt_feature_check_and_save_internal_value)
  cmake/QtFeature.cmake:606 (qt_evaluate_feature)
  cmake/QtFeature.cmake:575 (qt_feature_module_end)
  src/CMakeLists.txt:12 (qt_feature_evaluate_features)
```

So, unless I am missing something, it is Qt itself the one not producing OpenGL ES 2 support.

Am I missing something here?

Kinds regards, Lisandro.
#1035985#27
Date:
2023-06-06 05:40:09 UTC
From:
To:
Hi Lisandro,

I think I misunderstood the Qt documentation myself. It seems the
dynamic GLES support is only available on Windows, but the changes in
qt6 rendering would still minimize the requirements for rebuilt
packages.

It seems that it is only necessary to rebuild libqt6gui6 with
"-DINPUT_opengl=es2". Maybe you could make a new source package for
Qt6 Base on GLES and make it build libqt6gui6 and only it.

For reference, you can take a look at
https://github.com/cutie-shell/qt6-base/tree/feature/bookworm/gles_minimal/debian
. Note that you would need to use a different package name like
libqt6gui6-gles and it should provide and conflict with libqt6gui6.

Kind regards,
Erik Inkinen
#1035985#32
Date:
2023-06-06 14:40:57 UTC
From:
To:
Hi,

El martes, 6 de junio de 2023 02:40:09 -03 Erik Inkinen escribió:

There are at least two options:

1. Jump in to maintain it yourself. I'll be _more_than_happy_ to help as time allows it.
2. Find/Hire someone to do it.

This is specially true if your company uses Debian as a base for the containers shipped in your products (Leonardo: hint, hint).

Kinds regards, Lisandro.
#1035985#37
Date:
2023-06-07 17:15:39 UTC
From:
To:
Hello again Lisandro,
That's completely understandable.
I'll work a bit on this this week on our private Debian feed and then
start helping your team out, hopefully.
Should I keep in touch with your or Patrick Franz (listed as the
uploader)? Do you guys have an IRC I can jump in to?
Regards,
#1035985#42
Date:
2023-06-07 23:17:29 UTC
From:
To:
Hi!

Wonderful! I'll be delighted to help as I can!

Yes, jump in #debian-qt-kde on OFTC. I currently have my bouncer down,
but I hope to have it back soon.
#1035985#47
Date:
2023-06-07 23:23:16 UTC
From:
To:
On Wed, 7 Jun 2023 at 20:17, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> wrote:
You don't need to rebuild **everything**, just the pieces required for
QtGui.

https://salsa.debian.org/qt-kde-team/qt/qtbase/-/tree/gles/master?ref_type=heads

Also feel free to email me.
#1035985#52
Date:
2025-01-18 00:43:22 UTC
From:
To:
I'm not sure the bug subject is accurate for my 'bug' as I'm not having
errors, but there is a real possibility the configuration is not optimal
for 'embedded' systems, namely for OpenGL ES.
It's possible EGLFS is relevant here too.

With qt5 we had packages like libqt5gui5-gles which were used on armhf
and arm64 as those systems often had OpenGL ES, but not desktop OpenGL.

Wondering how that would be wrt qt6 landed me eventually on the buildd
log where I saw the following:

```
  OpenGL:
    Desktop OpenGL ....................... yes
    OpenGL ES 2.0 ........................ no
    OpenGL ES 3.0 ........................ no
    OpenGL ES 3.1 ........................ no
    OpenGL ES 3.2 ........................ no
...
QPA backends:
  DirectFB ............................... no
  EGLFS .................................. yes
  EGLFS details:
    EGLFS OpenWFD ........................ no
    EGLFS i.Mx6 .......................... no
    EGLFS i.Mx6 Wayland .................. no
    EGLFS RCAR ........................... no
    EGLFS EGLDevice ...................... yes
    EGLFS GBM ............................ yes
    EGLFS VSP2 ........................... no
    EGLFS Mali ........................... no
    EGLFS Raspberry Pi ................... no
    EGLFS X11 ............................ yes
```

https://buildd.debian.org/status/fetch.php?pkg=qt6-base&arch=arm64&ver=6.7.2%2Bdfsg-5&stamp=1733698782&raw=0

As most/all my arm64 systems use Mali graphics (panfrost driver), it
seems beneficial if "EGLFS Mali" would be "yes" and I guess others would
like to see "yes" for their preferred platform.
And the OpenGL ES <version> all have "no" where "yes" seems preferable
for 'embedded' systems?

So hereby the request to change the configuration to better (?) support
'embedded' platforms.

Reporting this from my PineTab2 which I'd be quite willing to use for
any (pre-release) build packages.

Cheers,
  Diederik