Bug 238513 – [GTK] EGLDisplay Initialization failed on Ubuntu 22.04 built without the wpe renderer

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKitGTK

[Jeremy Bicha]

webkit2gtk 2.35.90-1ubuntu1
Ubuntu 22.04 Beta

I am reporting this Ubuntu bug here for tracking.

All webkitgtk using apps just show a blank webview (either light with a light theme or dark with a dark theme). The cursor does change when hovering over invisible links.

When run from the command line this shows:
EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

This only happens when logged into a GNOME/Ubuntu on Wayland session. Either running in an Xorg session or with the WEBKIT_DISABLE_COMPOSITING_MODE=1 prefix works around the problem.

Other Information
=================
I believe this bug was triggered by the recent upgrade to mesa 22.0.

I think it might only affect Intel graphics.

My system according to GNOME has
Intel® Core™ i5-10310U CPU
Mesa Intel® UHD Graphics (CML GT2)

[Michael Catanzaro]

> I believe this bug was triggered by the recent upgrade to mesa 22.0.

Huh, here on Fedora 36 I only have mesa 21.3.8.

Is it possible to downgrade mesa to confirm that the mesa upgrade is to blame? That would help a lot.

[Jeremy Bicha]

Yes, the bug went away when I downgraded the mesa packages to 21.3.5-1ubuntu2

[Adrian Perez]

Further trying to help narrow down: I have Mesa 22.0 here and things
work fine, but my GPU is different (Intel HD Graphics 520 SKL GT2),
so this points towards either device-specific code, or towards the
Mesa driver chosen by the Mesa loader.

Note that there are two drivers: the traditional “i965” and the new
“iris” driver. Here I am using “iris” (and there is not even the other
installed).

You can set “MESA_LOADER_DRIVER_OVERRIDE=iris” if your GPU is supported
by the new driver and if things then work that will mean that the issue
is most likely the i965 driver. Alternatively, if Iris driver does not
support your GPU but Vulkan is supported, you can try the “zink” driver,
which implements OpenGL and GLES on top of Vulkan (and again, if that
works, then there is some bug in the Intel driver you are using :D)

I hope this helps!

[Jeremy Bicha]

The first 2 did not work for me but the 3rd did.

iris
----
$ MESA_LOADER_DRIVER_OVERRIDE=iris yelp
EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
Unsupported modifier, resource creation failed.
XXX: resource creation failed

zink
----
$ MESA_LOADER_DRIVER_OVERRIDE=zink yelp
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

i965
----
$ MESA_LOADER_DRIVER_OVERRIDE=i965 yelp
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)

WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
Nested Wayland compositor could not initialize EGL
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)

[Adrian Perez]

(In reply to Jeremy Bicha from comment #4)
> The first 2 did not work for me but the 3rd did.
> 
> iris
> ----
> $ MESA_LOADER_DRIVER_OVERRIDE=iris yelp
> EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
> Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
> Unsupported modifier, resource creation failed.
> XXX: resource creation failed
> 
> zink
> ----
> $ MESA_LOADER_DRIVER_OVERRIDE=zink yelp
> MESA-INTEL: warning: Performance support disabled, consider sysctl
> dev.i915.perf_stream_paranoid=0
> 
> MESA-INTEL: warning: Performance support disabled, consider sysctl
> dev.i915.perf_stream_paranoid=0
> 
> EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
> Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

Zink will use internally lower-level parts from the Iris driver to access
the hardware, so at least this indicates that the issue is *below* the
OpenGL/GLES implementation. Could be EGL or hardware access, I suppose.

> i965
> ----
> $ MESA_LOADER_DRIVER_OVERRIDE=i965 yelp
> libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so:
> cannot open shared object file: No such file or directory (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
> 
> WaylandCompositor requires eglBindWaylandDisplayWL,
> eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
> Nested Wayland compositor could not initialize EGL
> libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so:
> cannot open shared object file: No such file or directory (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)

When a driver that was set explicitly like this fails to load, Mesa falls
back to using software rendering. This means you ended up here using the
swrast/llvmpipe driver, most likely (you can load “webkit://gpu” in the
Minibrowser or Epiphany to check this). This means that WebKit is most
likely using the GLX/EGL/OpenGL/GLES APIs correctly and the issue lies
somewhere in the Intel driver.

But the version of Mesa I am using here is the same as you and it works.
My suspicion is that one of the following is happening:

 * Patches applied by Debian/Ubuntu on top of Mesa are breaking the Intel
   driver. Here I am using Arch Linux, which does not apply any patches.
 * The Intel driver is being miscompiled somehow by the compiler toolchain
   shipped by Ubuntu. In case it helps, here Arch stable has GCC 11.2.0 as
   the default system compiler, so that's what gets used to build packages.
 * The bug could be related to your particular GPU model (and the
   corresponding code inside Mesa for it).

I hope this helps :)

[Jeremy Bicha]

I reported this issue to Mesa also.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6236

[Marian Rainer-Harbach]

This issue occurs on my machine as well, which has an AMD GPU. So it does not seem to be directly related to the graphics driver in use.

[Michael Catanzaro]

(In reply to Marian Rainer-Harbach from comment #7)
> This issue occurs on my machine as well, which has an AMD GPU. So it does
> not seem to be directly related to the graphics driver in use.

Beware: if you're not certain the issue is caused by the same mesa 21.3 -> 22.0 upgrade, you might have a different underlying issue.

Anyway, I'm going to close this as MOVED since the issue is being tracked by mesa now and it seems unlikely that WebKit developers will be able to help more. We can reopen if the mesa issue gets closed.

[Jeremy Bicha]

A very important detail:
Ubuntu builds webkit2gtk with -DUSE_WPE_RENDERER=OFF
This was done because we would need Ubuntu Security Team sign off to get wpewebkit in to Ubuntu's 'main' archive section instead of in 'universe'.

It looks like this bug is specific to that config.

Copying from the mesa bug:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/6236#note_1329402

"The issue is that WebKitGTK's internal Wayland compositor needs to implement zwp_linux_dmabuf_v1 rather than relying on EGL_WL_bind_wayland_display.

In the meantime, we could revert the part which makes us strictly rely on dmabuf on the Mesa client side, and keep both in parallel for a little bit. But WebKitGTK should really be implementing this interface."

[Michael Catanzaro]

I've chatted with Jeremy about this, and he understands that -DUSE_WPE_RENDERER=OFF was intended to allow a transition period for distros to package libwpe and wpebackend-fdo, that WebKit developers don't test it anymore, and that Ubuntu needs to turn it on. I've also reported bug #238932 to consider making it mandatory in the GTK 4 version of WebKit.

In the meantime, I wonder how hard it would be to upgrade the legacy internal compositor to support zwp_linux_dmabuf_v1 so that Ubuntu doesn't have to patch mesa. No clue about that.

Adding some context, I disabled wpe in Ubuntu when we landed the version that added the option because the backend was new and our rules requires a review from our security and MIR teams before adding new main depends, which wasn't properly anticipated and not going to done for the incoming release of Ubuntu.

I should probably have done that by now but I the wpebackend package description in Debian states 'WebKit browser engine optimized for embedded devices' which made me wrongly assume that was not the preferred backend for a desktop usecase.

Which brings us back to today. The wpebackend package will be added to our review queue but that's not going to be processed in time for the incoming LTS so we will need another solution. The mesa upstream report suggests they might be wanting to add code to handle legacy clients (which webkitgtk built without wpe seems to be for that usecase?). Ideally the webkitgtk codepath not using WPE would also be fixed since that's an official upstream option. Our backup plan is probably to try to revert the changes from mesa if really needed

[Michael Catanzaro]

Is this still a problem?

[Carlos Garcia Campos]

wpe renderer is now mandatory, the nested wayland compositor was removed already.

For those whom it may help:

On Mint 22, xfce:

$ xreader
EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
Segmentation fault (core dumped)

However,

$ WEBKIT_DISABLE_COMPOSITING_MODE=1 xreader  # Starts normally

To make WEBKIT_DISABLE_COMPOSITING_MODE=1 the default;

$ sudo vi /etc/environment   # or nano

Add a new line to the file:

WEBKIT_DISABLE_COMPOSITING_MODE=1

[Michael Catanzaro]

In the past two years, the WPE renderer has itself also been removed. This bug is surely not relevant to anybody in 2024. You're hitting some other bug.