Bug 1128372

Description of problem:

Mesa is built with --enable-gallium-egl in rawhide/21. This flag enables the egl_gallium backend. I think that the egl_gallium backend is deprecated and Fedora should be using the egl_dri2 backend instead.

Running configure --help shows that --disable-gallium-egl is the default and emphasizes that this option is not required to use EGL (because the default egl_dri2 backend already supports the gallium device drivers). The implication is that you need a good reason to enable gallium-egl.

Mesa has been moving over to the egl_dri2 backend for some years. The mesa git logs for egl_dri2 (src/egl/drivers/dri2) and egl_gallium (src/gallium/state-trackers/egl) show that the overwhelming majority of development is now in the egl_dri2 backend. The few cases where egl_gallium offers advantages over egl_dri2 should disappear as development continues on egl_dri2 backend. On the other hand, the disadvantages in the egl_gallium backend may remain in place forever. Indeed, the egl_gallium backend may be dropped at some point to simplify the mesa code base. 

The mesa configure disables the egl_gallium backend by default because the default EGL backend changes from egl_dri2 to egl_gallium as soon as --enable-gallium-egl is set (see src/egl/main/egldriver.c). When the egl_gallium backend is enabled then the obscure environment variable EGL_DRIVER=egl_dri2 must be set to be certain of using the egl_dri2 backend.

One major disadvantage in the egl_gallium backend is its failure to implement gbm_surface_create under the drm platform. gbm_surface_create is vital to wayland compositors like weston or cogl. These compositors only run on Fedora rawhide because _eglMatchAndInitialize in src/egl/main/egldriver.c fallbacks to the egl_dri2 backend when the egl_gallium backend refuses to accept the gbm_device that the compositor created to use KMS. If the obscure environment variable GBM_BACKEND=gbm_gallium_drm.so is set then the compositors will create a gbm_device using the gbm_gallium backend. This gbm_device will then be accepted by the egl_gallium backend and the compositors will segfault when they try to call gbm_surface_create.

You should consult with the gallium, dri2 and freedreno developers before  disabling the egl_gallium backend, since there may be special cases where the egl_gallium backend is useful. I guess that the arm platform might be one case.