Source: mutter Version: 44.3-4 Severity: normal Tags: upstream X-Debbugs-Cc: debian-...@lists.debian.org User: debian-...@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