Bug#1050014: mutter: rethink the approach to forcing gles2 as default on armel, armhf

[Simon McVittie]

Source: mutter
Version: 44.3-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-arm at lists.debian.org
User: debian-arm at lists.debian.org
Usertags: armel armhf

mutter currently carries a non-upstreamable patch for its internal
fork of cogl, to make gles2 (as opposed to gl3) its default driver on
armel and armhf systems. This was explicitly rejected by upstream in
<https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/392>, so carrying
it as a downstream change is technical debt.

As per
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/392#note_527179
it seems that the patch is also ineffective/useless, because driver
selection is actually done at a higher level (in mutter's fork of clutter,
which is a higher layer than cogl).

Upstream, an anonymous user whose account has subsequently been deleted
writes:
> We have an ARM system with both a closed Mali driver stack and mesa
> installed, and we recently updated it from an old version of GNOME
> (before it carried cogl and clutter internally).
>
> Previously the cogl package would be built with the default driver
> option, which would cause cogl applications to start with GLESv2, using
> the mali stack and running "fast".
>
> Now we have libmutter-cogl built from packaging containing this
> patch. It sets the cogl default driver using vestigial code, but
> libmutter-clutter overrides that default, so this patch becomes
> meaningless and has no effect - GLX + gl3 is tried first, which for us
> means software rendering (not fast enough to use).

The higher-level driver selection code appears
to be in clutter_backend_real_create_context() in
clutter/clutter/clutter-backend.c, which as currently written will always
prioritize "desktop" GL as higher than GLESv2.

An upstream developer replied:
> IMHO the best way forward is to fix mutter/cogl's method for finding
> an appropriate configuration without the need for hard coding (in
> debian/...) it. Hard coding it there is just avoiding fixing the actual
> issue which is that mutter fails to do a good at configuring itself.
>
> E.g. if it first finds a workable configuration but it's software based,
> it should continue to find a better alternative and fall back to software
> as a last resort.

As a workaround, users of graphics stacks like the one described can set
the environment variable CLUTTER_DRIVER=gles2.

If armel/armhf users want mutter (and therefore GNOME Shell) to use
GLESv2 on systems that use a driver stack with accelerated GLESv2 but
unaccelerated GL, without needing such workarounds, then please contribute
a tested patch upstream that will have that effect. One way to achieve
this would be to iterate through known_drivers[] twice: the first time,
only accept hardware-accelerated contexts, and the second time, accept
software too. Alternatively, there could perhaps be some sort of detection
or workaround specifically for Mali hardware or the Mali proprietary driver.

I intend to remove the current non-upstreamable patch, because it isn't
having the desired effect, so it is just technical debt with no apparent
benefit to armel/armhf users.

Thanks,
    smcv