Hi Lyude, On Wed, May 30, 2018 at 9:31 PM, Lyude Paul <ly...@redhat.com> wrote: > NAK. I'm starting to see the problems with this approach I originally hit now. > > So: there's some unexpected catches when it comes to EGL client extensions. On > a system using glvnd with the nvidia driver, the EGL client extension list > will have /both/ the client extensions for the nvidia EGL driver and the > client extensions for the Mesa driver. An example from my test machine: > > EGL client extensions string: > EGL_EXT_platform_base EGL_EXT_device_base # ← nvidia! > EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions > EGL_KHR_debug EGL_EXT_platform_x11 EGL_EXT_platform_device > EGL_EXT_platform_wayland EGL_MESA_platform_gbm # ← mesa! > EGL_MESA_platform_surfaceless > > This is fine, but what it means is that we're going to have to take the > presence of either of these extensions as a sign that their respective EGL > backends -might- be there. e.g. we can't try to make a choice on avoiding > trying EGLStreams simply because GBM might be there, which is currently what > this patch does: > > * During init, xwl_glamor_should_use_gbm() tells us we should prefer GBM over > EGLStreams > * We select the gbm egl backend's hook for checking for the wl interfaces > * In xwl_screen_init(), we check for wl_drm and don't see it > * xwl_glamor_has_wl_interface() returns FALSE, which makes us disable glamor > and fall back to software rendering
I see... Problem is that we need to check for the interfaces and can do so only once we're connected to the Wayland display, after we called xwl_glamor_init_gbm() or xwl_glamor_init_eglstream() which setup the init_wl_registry() handler to read the wl_registry advertised by the compositor, and this is part of either xwl_gbm_private or xwl_eglstream_private structures which get allocated once we've selected the backend... So this is a chicken and egg situation here. So those interfaces for all backends, wl_drm, wl_eglstream_display, wl_eglstream_controller, and init_wl_registry() need to be moved out of the egl_backend, so that we can read *all* the available Wayland interfaces first and then decide which backend to use based on *both* EGL extensions available *and* Wayland interfaces as well. That's a bit of refactoring of the egl_backend code, working on it... [...] Cheers, Olivier _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel