Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wpewebkit 2.20.2, backend 0.2, fdo 0.1, cog 0.1] cog won't start #39

Closed
mrstinky opened this issue Sep 21, 2018 · 8 comments
Closed

[wpewebkit 2.20.2, backend 0.2, fdo 0.1, cog 0.1] cog won't start #39

mrstinky opened this issue Sep 21, 2018 · 8 comments

Comments

@mrstinky
Copy link

I've managed to build wpewebkit, but now I'm having trouble running cog.

Using: wpewebkit 2.20.2, backend 0.2, backend-fdo 0.1, cog 0.1
My configuration:

  • cog_git.bb - use cog-0.1 branch
  • wpebackend-fdo.inc: remove "virtual/libgl" from DEPENDS (see Does wpebackend-fdo actually need virtual/libgl? #33)
  • wpewebkit.inc: PACKAGECONFIG = "remote-inspector" (see [wpewebkit] build failure when REMOTE_INSPECTOR is not enabled #30)
  • conf/local.conf
    IMAGE_INSTALL_append = " wpewebkit cog"
    PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-fdo"
    DISTRO_FEATURES_append = " opengl"
    PREFERRED_VERSION_wpewebkit = "2.20.2
  • symlink: /usr/lib64/libWPEBackend-default.so -> /usr/lib64/libWPEBackend-fdo-0.1.so.0
  • XDG_RUNTIME_DIR='/run/user/root'
  • COG_URL='/home/root/test.html'

I have an instance of Weston running like so:
openvt -s weston --idle-time=4294967 --log=/tmp/weston.log

This is done by another team. It seems to work, and I can run simple EGL applications on it.

When I run cog:

# G_MESSAGES_DEBUG=all cog -P fdo
(cog:9769): Cog-DEBUG: platform_setup: Platform name: fdo
(cog:9769): Cog-DEBUG: platform_setup: Platform plugin: libcogplatform-fdo.so

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

(cog:9769): Cog-DEBUG: Instantiating default WPE backend as fall-back.
wpe: could not load the impl library. Is there any backend installed?: /usr/lib64/libWPEBackend-default.so: undefined symbol: wl_egl_window_destroy
Aborted (core dumped)
@philn
Copy link
Member

philn commented Sep 21, 2018

Looks like your wl_egl implementation is incomplete.

@mrstinky
Copy link
Author

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
Copy link
Author

mrstinky commented Sep 24, 2018

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
Copy link
Author

mrstinky commented Sep 25, 2018

@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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

aperezdc commented Oct 4, 2018

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants