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 +:
> 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
> , 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
> 
> (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

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

[Simon McVittie]

On Thu, 19 Jan 2023 at 14:12:28 +0900, Dominique Martinet wrote:
> 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?

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

(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

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

[Dominique Martinet]

Hi Simon,

Dominique Martinet wrote on Mon, Nov 28, 2022 at 11:47:07AM +0900:
> > I've added it to .
> 
> Thank you!

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

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

[Dominique Martinet]

Simon McVittie wrote on Fri, Nov 25, 2022 at 05:00:11PM +:
> On Thu, 29 Sep 2022 at 08:42:40 +0900, Dominique Martinet wrote:
> > 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.
> 
> I believe this is fixed in testing/unstable by 3.24.34-5 and 3.24.35,
> can you confirm?

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.


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

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.

> I've added it to .

Thank you!
-- 
Dominique

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

[Simon McVittie]

On Thu, 29 Sep 2022 at 08:42:40 +0900, Dominique Martinet wrote:
> 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.

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 .

smcv

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

[Dominique Martinet]

Hi,

Dominique Martinet wrote on Thu, Sep 29, 2022 at 08:42:40AM +0900:
> 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

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!
-- 
Dominique Martinet

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

[Dominique Martinet]

Package: libgtk-3-0
Version: 3.24.24-4+deb11u2
Severity: wishlist
Tags: patch

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?

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.145-0-at (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u2
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4+deb11u2
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4+deb11u2
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs  

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
pn  libcanberra-gtk3-module   
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information