[Webkit-unassigned] [Bug 201507] [GTK] Accelerated compositing is disabled due to failure in EGL display creation
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Jan 4 08:55:36 PST 2020
https://bugs.webkit.org/show_bug.cgi?id=201507
--- Comment #39 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Carlos Garcia Campos from comment #15)
> I'm checking logs reported in bug #202362.
>
> Oct 04 08:14:31 chargestone-cave org.gnome.Epiphany.Devel.desktop[1896]:
> Cannot get default EGL display: EGL_BAD_PARAMETER
> Oct 04 08:14:31 chargestone-cave org.gnome.Epiphany.Devel.desktop[1896]:
> Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
>
> This is the initialization of the default display, that is also failing so
> problem is not specific to wpe renderer. EGL_BAD_PARAMETER must be a
> previous error, as Miguel suggested, and the only egl call that should
> happen before the egl display initialization is eglGetPlatformDisplay. It
> returns a EGL_BAD_PARAMETER when the given platform is not supported, but if
> that was the case it would always fail. I see we are checking for
> EGL_KHR_platform_wayland and always passing EGL_PLATFORM_WAYLAND_KHR even
> when using eglGetPlatformDisplayEXT, but that shouldn't be a problem because
> EGL_PLATFORM_WAYLAND_KHR and EGL_PLATFORM_WAYLAND_EXT are both defined as
> 0x31D8.
>
> Oct 04 08:14:32 chargestone-cave org.gnome.Epiphany.Devel.desktop[1896]:
> Cannot get default EGL display: EGL_BAD_PARAMETER
> Oct 04 08:14:32 chargestone-cave org.gnome.Epiphany.Devel.desktop[1896]:
> PlatformDisplayLibWPE: could not create the EGL display: EGL_SUCCESS.
>
> And this is creating the share display for compositing. In this case I don't
> know here the EGL_BAD_PARAMETER comes from.
In desperation, I'm looking at eglapi.c in mesa:
static EGLBoolean EGLAPIENTRY
eglBindWaylandDisplayWL(EGLDisplay dpy, struct wl_display *display)
{
_EGLDisplay *disp = _eglLockDisplay(dpy);
_EGLDriver *drv;
EGLBoolean ret;
_EGL_FUNC_START(disp, EGL_OBJECT_DISPLAY_KHR, NULL, EGL_FALSE);
_EGL_CHECK_DISPLAY(disp, EGL_FALSE, drv);
assert(disp->Extensions.WL_bind_wayland_display);
if (!display)
RETURN_EGL_ERROR(disp, EGL_BAD_PARAMETER, EGL_FALSE);
ret = drv->API.BindWaylandDisplayWL(drv, disp, display);
RETURN_EGL_EVAL(disp, ret);
}
Could wl_display be NULL? It's created in the WS::Instance constructor in ws.cpp, in WPEBackend-fdo, using wl_display_create(). It's documented to return NULL on failure and it looks like a WPEBackend-fdo bug that it's not checking for possible failure there.
I know this isn't likely. We need better debugging to figure out what is going on. I've opened https://github.com/Igalia/WPEBackend-fdo/pull/89 to add debug crashes, which I recommend we use in production until we figure out what's going on here. (Otherwise, at the rate we're going, we might never find the bug.)
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200104/5ebc4220/attachment.htm>
More information about the webkit-unassigned
mailing list