Dear Maintainer,

when using GTK on platforms with a GLES-only GL implementation like some
raspberry pi or iMX platforms with vivante driver, GTK fails to
initialize its GL stack because it tries to bind to regular GL first
anyway before using the correct API as configured.

This can be tested by running gtk3-demo and the OpenGL area demo, which
will show nothing as no GL implementation could be found -- but it also
affects real GTK applications like epiphany (gnome web).

This was reported upstream a couple of years ago:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
and I submitted a patch yesterday:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062
(note as said there, this is already fixed in gtk 4)

Assuming the patch does get positive feedback and gets merged (I'm not
asking to backport some code before upstream review!!), what would the
way forward be?
gtk3 hasn't had a point release since May, and bullseye didn't get
updated to the latest stable release, so I assume we could backport the
patch? Would that be acceptable?

Hi,

Dominique Martinet wrote on Thu, Sep 29, 2022 at 08:42:40AM +0900:

This merge request has been merged, so I'd like to move this bug forward:
https://gitlab.gnome.org/GNOME/gtk/-/commit/0e5fe45ea20cce074a128911949dbedf4f8265bf

Is there any opposition to backporting it to debian stable (eventually
on next point update as this isn't a security fix, I'm not sure what the
exact process is here) ?


I'll be happy to do the actual package update work (adding the patch,
verifying it applies etc) but I don't want to step on any toes, so any
input is appreciated :)

Thanks!

I I believe this is fixed in testing/unstable by 3.24.34-5 and 3.24.35,
can you confirm?

This seems like a change in sufficiently core code that I would want to
watch for regressions in testing/unstable for some time before considering
a backport.

I've added it to <https://wiki.debian.org/Gnome/BullseyeUpdates>.

    smcv

Simon McVittie wrote on Fri, Nov 25, 2022 at 05:00:11PM +0000:

Thank you!

Unfortunately our openGL stack depends on proprietary binaries that I
cannot easily run on bookworm :(

I also couldn't just build the bookworm source package on bullseye, so
this won't be of much help, but I've confirmed that code-wise both
3.24.34-5 (patch in debian/ directory) and 3.24.35 (patch in orig
source) should be correct.
I'm currently building a local package with just that patch in our
debian/ folder so this much is at least known to work but I'd like to
provide a better feedback.

I'll give a try to openGL on bookworm again in the next few days and
report back if I can get it to work.

Right -- happy to wait a bit.

From my understanding of the code, the variable here would only be used
with `GDK_GL=gles` exported, and the only change here is briefly for
init to check a handful of egl extensions, so even if there are
platforms with both GL/GLES support and the variable is set to select
GLES the current result would be incorrect and things should only work
better.

As usual, the difference between theory and practice is practice, so
I agree we can/should give it a bit more time to get feedback first.

Thank you!

Hi Simon,

Dominique Martinet wrote on Mon, Nov 28, 2022 at 11:47:07AM +0900:

Just a follow-up on this proposed updates mechanism -- it looks like
this wasn't included in the december 11.6 point update (as expected,
since we agreed to let it be tested for a bit), is there anything I
should/can do to make sure the next 11.7 gets gtk+3.0 3.24.34-5, or is
that still too early?

(there doesn't seem to be any plan for 11.7 yet, release.debian.org says
"maybe mid-February", but I assume it will be harder to justify adding
it once bookworm is released in a few more months and bullseye gets
branded oldstable so next release sounds optimal for me)


Thank you,

11.7 will not get gtk+3.0_3.24.34-5, regardless. The changes between
3.24.24 and 3.24.34 are too extensive to ask the release team to review
them (1242 lines of changes in gtk/gtkimcontextsimple.c alone) and have
triggered serious regressions in the past, although I hope all the known
regressions are now fixed for Debian 12.

What *could* go into either 11.7 or a later 11.x point release is a
version derived from the version 3.24.24-4+deb11u2 currently in stable,
with the change that fixes GLES-only platforms applied as a patch. It
would end up versioned as 3.24.24-4+deb11u3, unless it gets preempted
by an urgent security fix or something like that.

Is upstream commit 0e5fe45ea20cce074a128911949dbedf4f8265bf, from
<https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062>, necessary
and sufficient to fix this in the 3.24.24 codebase? Or are there other
changes required?

If upstream !5062 is believed to be sufficient, please try building
<https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/13>
(it can be built with git-buildpackage, or let me know if you need a
complete source package), and verify that it solves the problem for you
on your GLES-only device(s)/driver(s).

Also, please check that what I've written in the changelog is accurate.
I don't think I had fully realised until I looked again at this patch
that while your bug report talks about GTK failing to use GL on GLES-only
platforms and doesn't mention X11 vs. Wayland, your patch only changes
the Wayland code path. From a quick look at gdk/x11/gdkglcontext-x11.c,
it seems your change is making the Wayland/EGL code path match what
X11/GLX already did, and so you could have worked around this bug with
GDK_BACKEND=x11, except that presumably you'd prefer to have the benefits
of using native Wayland?

The other testing that is needed on this version is to confirm that
it doesn't break anything on Debian 11 systems where "desktop" OpenGL
*is* available, such as ordinary x86 PCs, and presumably also embedded
systems that use Mesa (such as the etnaviv driver). I can try it on x86,
but any testing you can do on this would also improve our confidence
about this backport.

Thanks,
    smcv

Simon McVittie wrote on Thu, Jan 19, 2023 at 11:22:29AM +0000:

Ah, I had misread that as 24-4 -> 24-5 (or 34-4 -> 34-5), 24->34 is
indeed quite bigger; sorry or the confusion.

That'd be appreciated !

Yes, that commit is necessary & sufficient for my use-case.

I'll try that today and report back directly on the MR.
While the build runs I've run a diff with the local package I've been
using since late September and changelog entry / name of the patch file
aside the content is identical, so I do not expect any problem for our
workload, but might as well make sure.

The changelog entry looks good to me, I'll comment on salsa directly to
leave a trace.
I can confirm that affects only wayland, the purpose of this patch is to
allow epiphany(/WebkitGTK) to run in a kiosk environment and having less
moving parts is appreciable, we currently run without Xwayland so I did
not actually test the X11 backend.

I'm afraid I also won't be of much help here; my understanding is that
it would also help there (in case both GL and GLES are available,
forcing GLES would still be querying GL for init properties and would
incorrectly try to use potentially missing extensions), but I do not
have any such system to test...
For a "more normal" x86/intel system I'm running bookworm so indirectly
have that patch through 3.24.36-1 and just tested various combinaisons
of setting GDK_GL=gles or not, wayland or native X11, and it all seems
to work properly.
(I'd test the proposed package, but I do not have any stable system with
a destkop environment available right now, sorry)


Thank you for your time and explanations, I'll follow up on salsa unless
prompted here.

We believe that the bug you reported is fixed in the latest version of
gtk+3.0, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1020937@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated gtk+3.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 24 Feb 2023 19:07:01 +0000
Source: gtk+3.0
Architecture: source
Version: 3.24.24-4+deb11u3
Distribution: bullseye
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1020937
Changes:
 gtk+3.0 (3.24.24-4+deb11u3) bullseye; urgency=medium
 .
   * d/p/gdk_wayland_display_init_gl-use-GLES-API-if-required.patch:
     Apply patch from 3.24.35 to fix Wayland + EGL on GLES-only platforms.
     Previously, GTK assumed that EGL could use the OpenGL API everywhere,
     but some proprietary drivers like those for Raspberry Pi and Vivante
     only support OpenGL ES. Allow use of OpenGL ES to be forced via
     environment variable GDK_GL=gles.
     Thanks to Dominique Martinet (Closes: #1020937)
Checksums-Sha1:
 0b415aa0cb1c458359848b9adc84d442d5484b45 4145 gtk+3.0_3.24.24-4+deb11u3.dsc
 2fb584297354b9ef43b38bace6c165a2f150d0cc 173168 gtk+3.0_3.24.24-4+deb11u3.debian.tar.xz
 0ff2f382e84136065c98f13a2ea925bfec6f3bd5 15622 gtk+3.0_3.24.24-4+deb11u3_source.buildinfo
Checksums-Sha256:
 d4d5b771e8454e8bcf36da82aabea4f402654cc03bff248858dacc1e031082dc 4145 gtk+3.0_3.24.24-4+deb11u3.dsc
 b6909988a0a973f1a985c9ea7b588d8681824203f0d8bf0361737c428d796cc8 173168 gtk+3.0_3.24.24-4+deb11u3.debian.tar.xz
 493cf22a5d235fe3b6f63b66f5e83cec8a6fe697f6ccec52a60524593e197b93 15622 gtk+3.0_3.24.24-4+deb11u3_source.buildinfo
Files:
 c9f9a4ffd8a456c4a79929c3a7c2bdf8 4145 libs optional gtk+3.0_3.24.24-4+deb11u3.dsc
 e875d91d7b85af03b3eae1f6df497909 173168 libs optional gtk+3.0_3.24.24-4+deb11u3.debian.tar.xz
 5f1d05d3d3cf8f3f15150503c3d6fb56 15622 libs optional gtk+3.0_3.24.24-4+deb11u3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmQpdEEACgkQ4FrhR4+B
TE+UHw/+KBXWgA+yZl/h/8VFbPnVvb7nlQW/F6JhDQ8m2XLpL7/WM7eCzqTWDW7+
tzemv5YromHhO+YtcOMlEywZ2VgpjG+yJhCxT/3StQgKgP6ruV6tov2Di9DSI4Jp
xhvgy0g3bVtT1FY5MZKcFdsreTd3yE4JHCiiSk67t3UnldR7NNWPxt1KcwWA9EFP
qlbAJqQ2kTARtbhPEAsbZtZu4JiHB4z+1mpXnTkg1cCst8ym3nrr+oIC9uLAh5UN
B8HCSHRimHkE/8AyROmSwaNrf3CtXFTNUMHMiYYBJnyufXRhrYxurwXddZyb6gYJ
+YyQnNfg+amIY8B84RYwz4N0KHvmFfde2RNPCSYuWSlKD0yIaXm4CBT11AxwDuOe
FHGDTT0FiPPv8MV7m7mBBSBB1vf2J+SOrWDAFyuXQjIgeROnVy0mXxSCAIwA7QoA
3So31Ba83XfuxrHntyu1IXTlVNnBnIbOG2VX8kkAqgQyPw8OFStbpMr52g60CAGP
BwKhZ0XLziwzqx2jAVaUsRZ42gCxwkdW/uyFcTjK8ppcOFJ3UNkplam+3eo+o1An
qGV9nFbXSXtk4nZ25qiUnsyeypWnAdexFS650fH9VN3brdJQrkNKvEYvVnvPfQJU
Ya6lGc5s2ojOJ7yCffEJ3apfA7Iq112Fqb+PSnZMLqO/uKn5hxE=
=D/8I
-----END PGP SIGNATURE-----