[wpewebkit 2.20.2, backend 0.2, fdo 0.1, cog 0.1] cog won't start about meta-webkit

[philn]

Looks like your wl_egl implementation is incomplete.

[mrstinky]

Is not being able to load "libcogplatform-fdo.so" a problem?

The symbol wl_egl_window_destroy appears to be defined in libwayland-egl, and undefined in libWPEBackend-fdo-0.1.

$ nm -D ./usr/lib64/libwayland-egl.so.1 | grep wl_egl_window_destroy
...
0000000000000be0 T wl_egl_window_destroy

$ nm -D ./usr/lib64/libWPEBackend-fdo-0.1.so | grep  wl_egl_window_destroy
                 U wl_egl_window_destroy

So I tried preloading libwayland-egl, and it doesn't complain about the undefined symbol.

# export LD_PRELOAD="/usr/lib64/libwayland-egl.so"
# G_MESSAGES_DEBUG=all cog -P fdo
(cog:10167): Cog-DEBUG: platform_setup: Platform name: fdo
(cog:10167): Cog-DEBUG: platform_setup: Platform plugin: libcogplatform-fdo.so

(cog:10167): Cog-WARNING **: Could not load: libcogplatform-fdo.so (possible cause: Socket operation on non-socket).

(cog:10167): Cog-DEBUG: Instantiating default WPE backend as fall-back.

** (cog:10167): CRITICAL **: WebKitWebViewBackend* webkit_web_view_backend_new(wpe_view_backend*, GDestroyNotify, gpointer): assertion 'backend' failed

(cog:10167): Cog-ERROR **: Could not instantiate any WPE backend.
Trace/breakpoint trap (core dumped)

[mrstinky]

My build is for ARM64, so I manually updated the ldconfig for the /usr/lib64 directories, and set the LD_PRELOAD for the undefined symbol.

I re-ran cog, and got the following.

# ldconfig /lib /usr/lib /lib64 /usr/lib64
# export COG_URL="/home/root/test.html"
# export LD_PRELOAD="/usr/lib64/libwayland-egl.so"
# export XDG_RUNTIME_DIR=/run/user/root
# cog -P fdo

Wayland: Got a wl_compositor interface
Wayland: Got a wl_seat interface
Wayland: Got an xdg_shell interface
Wayland: Got a wl_shell interface
GBM_INFO::msmgbm_mapper(125)::gbm mapper instantiated
	
gbm_create_device(156): Info: backend name is: fb
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
Seat caps: Keyboard 
Seat name 'default'
New XDG toplevel configuration: (0, 0)
EGLDisplay Initialization failed: EGL_BAD_ALLOC
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
Cog-Message: <file:///home/root/test.html> Load started.
Cog-Message: <file:///home/root/test.html> Loading...
Cog-Message: <file:///home/root/test.html> Loaded successfully.

[mrstinky]

@philn @aperezdc @clopez

UPDATE: I switched to the RDK + Wayland backend, and it's working. I couldn't get it working with the FDO backend.

I'm trying to figure out why my wpewebkit won't initialize the display. I'm not an expert in EGL and Weston, so I need some help here.

I have a simple-egl application running on my Weston display, so I know my display is working. Now I'm looking at the difference between the two initialization styles.

Webkit is doing: eglGetDisplay(...) and then eglInitialize(...)

simple-egl is doing: weston_platform_get_egl_display(EGL_PLATFORM_WAYLAND_KHR, ...) and then eglInitialize(...)

I did some research on simple-egl.c, and I see that there are two different "styles" to initialize EGL:
https://github.com/wayland-project/weston/blob/master/clients/simple-egl.c#L165
https://github.com/krh/weston/blob/master/clients/simple-egl.c#L127

Which is the "right" one, and why do they differ?

I'm looking at the files in Source/WebCore/platform, and trying to understand the difference between platform Wayland and platform WPE. What is the fundamental difference between these two, and do they both work with Weston?

grepping for EGL_PLATFORM_WAYLAND_KHR shows that it exists in graphics/wayland/PlatformDisplayWayland.cpp but not in graphics/wpe/....

This seems to hint to me that I should be using platform Wayland.

[aperezdc]

It definitely looks like something funny is going on when linking libcogplatform-fdo.so — there should not be undefined symbols when the library is dlopen()ed.

The different initialization style for getting the EGL display should be basically equivalent, with weston_platform_get_egl_display apparently being a wrapper around eglGetPlatformDisplay which is explicit about the type of display to use. While a plain eglGetDisplay should choose the correct one automatically, there can be situations in which being explicit may be needed.

From the line that reads GBM_INFO::msmgbm_mapper(125)::gbm mapper instantiated it looks like you have an Adreno GPU. Can you confirm this? If yes, which model and driver are you using? That would be useful because sometimes EGL implementations behave in slightly different ways, and it may be that in your case it would be needed to use eglGetPlatformDisplay to be explicit about the kind of display we want to use.

[aperezdc]

As a matter of fact, it would be indeed a good idea to use eglGetPlatformDisplay when it's available, so I have filed an issue for that: Igalia/cog#64 — note that I do not know if that will be enough to fix your issue, but it should at least help to make sure EGL is being initialized in the way we need it.

[mrstinky]

It definitely looks like something funny is going on when linking libcogplatform-fdo.so — there should not be undefined symbols when the library is dlopen()ed.

I think that was fixed by ldconfig. I was manually pushing the libraries to target, instead of using the Yocto images. Once I reloaded the ldconfig cache, the problem went away.

it looks like you have an Adreno GPU. Can you confirm this? If yes, which model and driver are you using?

It's an Adreno 306, and the driver is new, but soon to be released. I've been working closely with the GPU team to make sure our driver "just builds" with webkit, and other OS libraries. So far so good, as I can build webkit against our driver without any modifications.

Thanks for the help.

[aperezdc]

@mrstinky Glad you got the issue solved. I still is a good idea to use eglGetPlatformDisplay where available, so it has been valuable that you have stopped by and reported the issue to make me think about that. Thanks!

Also: I am looking forward to having an Adreno driver with Wayland support, that will be great!