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)
> 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.
Yes, the bug went away when I downgraded the mesa packages to 21.3.5-1ubuntu2
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!
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)
(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 :)
I reported this issue to Mesa also. https://gitlab.freedesktop.org/mesa/mesa/-/issues/6236
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.
(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.
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."
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
Is this still a problem?
wpe renderer is now mandatory, the nested wayland compositor was removed already.