Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Simon McVittie wrote on Thu, Jan 19, 2023 at 11:22:29AM +0000:
> 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.

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.

> 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.

That'd be appreciated !

> 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?

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

> 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).

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.

> 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 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.

> 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.

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.
-- 
Dominique