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