Bug 178896 – [WPE] Can't run dyz

• Component: WPE WebKit
• Status: RESOLVED FIXED

[Michael Catanzaro]

I've built WPE and attempted to run dyz using the following steps:

$ update-webkitwpe-libs
$ build-webkit --wpe
$ run-minibrowser --wpe

It fails to create a window. Output is as follows:

Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
PlatformDisplayWPE: could not create the EGL display.
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

(gst-plugin-scanner:16711): GStreamer-WARNING **: Failed to load plugin '/home/mcatanzaro/Projects/WebKit/WebKitBuild/DependenciesWPE/Root/lib/gstreamer-1.0/libgstpango.so': /lib64/libpango-1.0.so.0: undefined symbol: g_log_structured

The gst-plugin-scanner error is caused because our JHBuild environment is incomplete and missing pango. That'll have to be added, or GStreamer will never work inside the JHBuild environment. I'll file a separate bug for that.

I don't know about the xkbcommon warning. I'll file another bug for that too.

I suspect the main problem here is PlatformDisplayWPE: could not create the EGL display. I'll add some debug to PlatformDisplay and try to figure out what's going on there.

[Michael Catanzaro]

I've tried Adrian's patch in bug #178937. Now I get a slightly more useful error:

PlatformDisplayWPE: could not create the EGL display: EGL_SUCCESS.
Cannot create EGL context: invalid display (last error: EGL_BAD_PARAMETER)

I also tried running with EGL_PLATFORM=wayland in my environment. (In addition to WAYLAND_DISPLAY=wayland-0 which is set by default on Fedora.) Now the error message is a bit different:

PlatformDisplayWPE: could not create the EGL display: EGL_BAD_PARAMETER.
Cannot create EGL context: invalid display (last error: EGL_BAD_PARAMETER)

[Michael Catanzaro]

Adrian gave me more environment variables to play with:

$ EGL_PLATFORM=wayland WAYLAND_DEBUG=1 MESA_DEBUG=context EGL_DEBUG=verbose run-minibrowser --wpe
Starting dyz 
[1770161.989]  -> [e-mail]_registry(new id wl_registry@2)
[1770162.012]  -> [e-mail](new id wl_callback@3)
[1770162.100] [e-mail]_id(3)
[1770162.135] [e-mail](1, "wl_drm", 2)
[1770162.142]  -> [e-mail](1, "wl_drm", 2, new id [unknown]@4)
[1770162.155] [e-mail](2, "wl_compositor", 3)
[1770162.164]  -> [e-mail](2, "wl_compositor", 1, new id [unknown]@5)
[1770162.175] [e-mail](3, "wl_shm", 1)
[1770162.181]  -> [e-mail](3, "wl_shm", 1, new id [unknown]@6)
[1770162.187] [e-mail](4, "wl_output", 2)
[1770162.195] [e-mail](5, "wl_data_device_manager", 3)
[1770162.204]  -> [e-mail](5, "wl_data_device_manager", 2, new id [unknown]@7)
[1770162.215] [e-mail](6, "gtk_primary_selection_device_manager", 1)
[1770162.224] [e-mail](7, "zxdg_shell_v6", 1)
[1770162.232]  -> [e-mail](7, "zxdg_shell_v6", 1, new id [unknown]@8)
[1770162.246] [e-mail](8, "wl_shell", 1)
[1770162.254] [e-mail](9, "gtk_shell1", 1)
[1770162.265] [e-mail](10, "wl_subcompositor", 1)
[1770162.273] [e-mail](11, "zwp_pointer_gestures_v1", 1)
[1770162.283] [e-mail](12, "zwp_tablet_manager_v2", 1)
[1770162.292] [e-mail](13, "wl_seat", 5)
[1770162.301]  -> [e-mail](13, "wl_seat", 4, new id [unknown]@9)
[1770162.312] [e-mail](14, "zwp_relative_pointer_manager_v1", 1)
[1770162.323] [e-mail](15, "zwp_pointer_constraints_v1", 1)
[1770162.330] [e-mail](16, "zxdg_exporter_v1", 1)
[1770162.338] [e-mail](17, "zxdg_importer_v1", 1)
[1770162.348] [e-mail](20642)
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
[1770162.548]  -> [e-mail]_surface(new id wl_surface@3)
[1770162.557]  -> [e-mail]_xdg_surface(new id zxdg_surface_v6@10, wl_surface@3)
[1770162.566]  -> [e-mail]_toplevel(new id zxdg_toplevel_v6@11)
[1770162.573]  -> [e-mail]_title("WPE")
[1770162.578]  -> [e-mail]()
[1770165.028] [e-mail](3)
[1770165.040]  -> [e-mail]_pointer(new id wl_pointer@12)
[1770165.047]  -> [e-mail]_keyboard(new id wl_keyboard@13)
[1770165.052] [e-mail]("seat0")
[1770165.057] [e-mail](0, 0, array)
[1770165.067] [e-mail](20643)
[1770165.074]  -> [e-mail]_configure(20643)
[1770168.708] [e-mail](1, fd 11, 52285)
[1770170.675] [e-mail]_info(33, 500)
PlatformDisplayWPE: could not create the EGL display: EGL_BAD_PARAMETER.
Cannot create EGL context: invalid display (last error: EGL_BAD_PARAMETER)
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

[Michael Catanzaro]

*** Bug 174669 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

OK, I see on https://trac.webkit.org/wiki/WPE:

"The device files /dev/dri/renderD128 and /dev/dri/controlD64 have to exist and your user need write access to them (On most distributions this means ensuring your user is member of a group named "video")"

Two problems here:

 * /dev/dri/controlD64 does not exist at all on my machine. What is supposed to create this?
 * My user is not in the video group, but that is required to write to /dev/dri/renderD128.

This is bad. How is this really supposed to work? I don't think changing group membership should be required to run WPE.

$ ls -hal
total 0
drwxr-xr-x.  3 root root       100 Oct 30 08:24 .
drwxr-xr-x. 19 root root      4.1K Oct 30 08:24 ..
drwxr-xr-x.  2 root root        80 Oct 30 08:24 by-path
crw-rw----+  1 root video 226,   0 Oct 30 08:24 card0
crw-rw----+  1 root video 226, 128 Oct 30 08:24 renderD128

[Michael Catanzaro]

It looks like the group membership is not needed, at least not on Fedora, due to the its:

$ getfacl renderD128 
# file: renderD128
# owner: root
# group: video
user::rw-
user:mcatanzaro:rw-
group::rw-
mask::rw-
other::---

Not sure what sets that up, but whatever. So the remaining question is: why does /dev/dri/controlD64 not exist?

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #5)
> It looks like the group membership is not needed, at least not on Fedora,
> due to the its:
> 
> $ getfacl renderD128 
> # file: renderD128
> # owner: root
> # group: video
> user::rw-
> user:mcatanzaro:rw-
> group::rw-
> mask::rw-
> other::---
> 
> Not sure what sets that up, but whatever. So the remaining question is: why
> does /dev/dri/controlD64 not exist?

I think that's a typo on the doc. I have updated it.

The devices needed are /dev/dri/card0 and /dev/dri/renderD128.

For example, I have this:

$ ls -l /dev/dri/
total 0
crw-rw----+ 1 root video 226,   0 Oct 30 11:05 card0
crw-rw----+ 1 root video 226,   1 Oct 30 11:05 card1
crw-rw----+ 1 root video 226, 128 Oct 30 11:05 renderD128
crw-rw----+ 1 root video 226, 129 Oct 30 11:05 renderD129

And my user is member of the video group (as reported by the groups command)

In my case, as I have two GPUs, card0 and renderD128 are from the Intel GPU, and card1 and renderD129 are from a NVIDIA card.

By default, WPEBackend-mesa will pick the first card (card0 and renderD128).
So having card0 and renderD128 with write access for your user should be enough.

If you have more than one GPU and you can give a try to using the second one then you can play with the environment variables WPE_RENDER_NODE and WPE_RENDER_CARD

[Adrian Perez]

(In reply to Michael Catanzaro from comment #5)
> It looks like the group membership is not needed, at least not on Fedora,
> due to the its:
> 
> $ getfacl renderD128 
> # file: renderD128
> # owner: root
> # group: video
> user::rw-
> user:mcatanzaro:rw-
> group::rw-
> mask::rw-
> other::---

In my case I had already noticed this, and using ACLs is fine. Most
modern GNU/Linux have been using ACLs since tmpfs/devtmpfs gained
support for them a few years ago.
 
> Not sure what sets that up, but whatever. So the remaining question is: why
> does /dev/dri/controlD64 not exist?

Some time ago this device node from the DRM subsystem was renamed to
“cardX”, so the “/dev/dri/card0” is what is used nowadays. If you look
under “/sys” the kernel still advertises “controlD64” as a symlink to
“card0”:

  % ls -l /sys/class/drm/card0/device/drm/controlD64 
  lrwxrwxrwx 1 root root 0 oct 30 16:57 /sys/class/drm/card0/device/drm/controlD64 -> card0/

I tried to symlink “/dev/dri/controlD64 -> “/dev/dri/card0” to no avail.


(BTW, if the WebKit or WPE code has “controlD64” hardcoded somewhere,
well then we should fix it, but I doubt that's the case ;-D)

[Michael Catanzaro]

OK, so that was a false alarm... we should probably focus on the error message:

PlatformDisplayWPE: could not create the EGL display: EGL_SUCCESS.
Cannot create EGL context: invalid display (last error: EGL_BAD_PARAMETER)

Seems safe to conclude that there is a bug in the EGL setup code somewhere. Also,  from the EGL_SUCCESS, I conclude there is a bug in Adrian's error message patch. ;)

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #5)
> It looks like the group membership is not needed, at least not on Fedora,
> due to the its:

I meant to say: "due to its ACL"

[Miguel Gomez]

In my system I can see the call to gbm_create_device() using the file descriptor of /dev/dri/renderD128 succeeding. That device is passed to eglGetDisplay() in PlatformDisplayWPE, but that call is returning EGL_NO_DISPLAY for some reason.

[Carlos Alberto Lopez Perez]

Can you try to apply this patch http://sprunge.us/UCQd and run it as follows:

export INTEL_DEBUG=dri,fbo
Tools/Scripts/run-minibrowser --wpe 


I get this:

$ INTEL_DEBUG=dri,fbo Tools/Scripts/run-minibrowser --wpe 
Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
INFO: GBM device is /dev/dri/renderD128 and GBM backend is drm
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT: MESA_FORMAT_Z24_UNORM_X8_UINT (800x600)
intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX: MESA_FORMAT_S_UINT8 (800x600)
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60
enter intel_update_renderbuffers, drawable 0x7f6bcc028a60


Note: I'm running dyz inside Weston inside x11 (which is currently broken for me since r222804 and I fixed locally with https://github.com/WebPlatformForEmbedded/WPEBackend-mesa/pull/7)

[Michael Catanzaro]

$ INTEL_DEBUG=dri,fbo run-minibrowser --wpe --debug
Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
INFO: GBM device is /dev/dri/renderD128� and GBM backend is drm
PlatformDisplayWPE: could not create the EGL display.
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

Note that's U+FFFD 'Replacement Character' that I see on my terminal in the device name, which doesn't seem right.

[Michael Catanzaro]

Note also: I'm using mutter, yes, and also our WPE JHBuild environment.

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #12)
> $ INTEL_DEBUG=dri,fbo run-minibrowser --wpe --debug
> Starting dyz 
> xkbcommon: ERROR: couldn't find a Compose file for locale "C"
> INFO: GBM device is /dev/dri/renderD128� and GBM backend is drm
> PlatformDisplayWPE: could not create the EGL display.
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will
> not be saved or shared with other applications.
> 
> Note that's U+FFFD 'Replacement Character' that I see on my terminal in the
> device name, which doesn't seem right.

That's likely a bug on my patch, as it seems readlink() doesn't add \0 to the end of the string by default and I didn't initialized it before. So that character is perhaps random garbage from the memory.

I think this should fix that:

-    char deviceName[PATH_MAX];
+    char deviceName[PATH_MAX] = {};


Can you test this? if this is right we may have a similar issue in GLibUtilities.cpp

[Carlos Alberto Lopez Perez]

(In reply to Carlos Alberto Lopez Perez from comment #14)
> Can you test this? if this is right we may have a similar issue in
> GLibUtilities.cpp

It seems it isn't a bug there as the variables are declared static there... and those are automatically initialized to zero.

[Michael Catanzaro]

With INTEL_DEBUG=all:

$ INTEL_DEBUG=all run-minibrowser --wpe --debug
Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
bo_create: buf 1 (swizzle test) 32768b
bo_unreference final: 1 (swizzle test)
INFO: GBM device is /dev/dri/renderD128t� and GBM backend is drm
PlatformDisplayWPE: could not create the EGL display.
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #14)
> Can you test this? if this is right we may have a similar issue in
> GLibUtilities.cpp

That fixes it, now the GBM device is just "/dev/dri/renderD128".

[Carlos Alberto Lopez Perez]

Michael... can you test this patch http://sprunge.us/ZDWV ? Does it make any 
difference?

[Michael Catanzaro]

Yeah, it makes it worse I'm afraid:

$ INTEL_DEBUG=all run-minibrowser --wpe --debug
Starting dyz 
xkbcommon: ERROR: couldn't find a Compose file for locale "C"
bo_create: buf 1 (swizzle test) 32768b
bo_unreference final: 1 (swizzle test)
No provider of eglGetPlatformDisplayEXT found.  Requires one of:
    EGL extension "EGL_EXT_platform_base"

[Michael Catanzaro]

I Carlos Lopez's debug tool https://github.com/clopez/waylandeglinfo

$ ./waylandes2info 
EGL_VERSION = 1.4 (DRI2)
EGL_VENDOR = Mesa Project
EGL_EXTENSIONS = EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_swap_buffers_with_damage EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image 
EGL_CLIENT_APIS = OpenGL OpenGL_ES 
GL_VERSION: OpenGL ES 3.1 Mesa 17.2.2
GL_RENDERER: Mesa DRI Intel(R) Haswell Desktop 
GL_EXTENSIONS:
    GL_EXT_blend_minmax, GL_EXT_multi_draw_arrays, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_compression_dxt1, 
    GL_EXT_texture_format_BGRA8888, GL_OES_compressed_ETC1_RGB8_texture, 
    GL_OES_depth24, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 
    GL_OES_mapbuffer, GL_OES_rgb8_rgba8, GL_OES_standard_derivatives, 
    GL_OES_stencil8, GL_OES_texture_3D, GL_OES_texture_float, 
    GL_OES_texture_float_linear, GL_OES_texture_half_float, 
    GL_OES_texture_half_float_linear, GL_OES_texture_npot, 
    GL_OES_vertex_half_float, GL_EXT_texture_sRGB_decode, GL_OES_EGL_image, 
    GL_OES_depth_texture, GL_OES_packed_depth_stencil, 
    GL_EXT_texture_type_2_10_10_10_REV, GL_OES_get_program_binary, 
    GL_APPLE_texture_max_level, GL_EXT_discard_framebuffer, 
    GL_EXT_read_format_bgra, GL_EXT_frag_depth, GL_NV_fbo_color_attachments, 
    GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_vertex_array_object, 
    GL_OES_viewport_array, GL_ANGLE_texture_compression_dxt3, 
    GL_ANGLE_texture_compression_dxt5, GL_EXT_robustness, GL_EXT_texture_rg, 
    GL_EXT_unpack_subimage, GL_NV_draw_buffers, GL_NV_read_buffer, 
    GL_NV_read_depth, GL_NV_read_depth_stencil, GL_NV_read_stencil, 
    GL_EXT_draw_buffers, GL_EXT_map_buffer_range, GL_KHR_debug, 
    GL_KHR_robustness, GL_OES_depth_texture_cube_map, 
    GL_OES_surfaceless_context, GL_EXT_color_buffer_float, 
    GL_EXT_separate_shader_objects, GL_EXT_shader_integer_mix, 
    GL_EXT_tessellation_point_size, GL_EXT_tessellation_shader, 
    GL_INTEL_performance_query, GL_EXT_compressed_ETC1_RGB8_sub_texture, 
    GL_EXT_draw_buffers_indexed, GL_EXT_draw_elements_base_vertex, 
    GL_EXT_gpu_shader5, GL_EXT_polygon_offset_clamp, 
    GL_EXT_primitive_bounding_box, GL_EXT_shader_io_blocks, 
    GL_EXT_texture_border_clamp, GL_EXT_texture_buffer, 
    GL_EXT_texture_cube_map_array, GL_KHR_blend_equation_advanced, 
    GL_KHR_context_flush_control, GL_KHR_robust_buffer_access_behavior, 
    GL_NV_image_formats, GL_OES_draw_buffers_indexed, 
    GL_OES_draw_elements_base_vertex, GL_OES_gpu_shader5, 
    GL_OES_primitive_bounding_box, GL_OES_sample_shading, 
    GL_OES_sample_variables, GL_OES_shader_io_blocks, 
    GL_OES_shader_multisample_interpolation, GL_OES_tessellation_point_size, 
    GL_OES_tessellation_shader, GL_OES_texture_border_clamp, 
    GL_OES_texture_buffer, GL_OES_texture_cube_map_array, 
    GL_OES_texture_stencil8, GL_OES_texture_storage_multisample_2d_array, 
    GL_EXT_blend_func_extended, GL_EXT_buffer_storage, 
    GL_EXT_geometry_point_size, GL_EXT_geometry_shader, 
    GL_EXT_shader_samples_identical, GL_KHR_no_error, 
    GL_OES_geometry_point_size, GL_OES_geometry_shader, 
    GL_OES_shader_image_atomic, GL_EXT_clip_cull_distance, 
    GL_MESA_shader_integer_functions

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #2)
> Adrian gave me more environment variables to play with:
> 
> $ EGL_PLATFORM=wayland WAYLAND_DEBUG=1 MESA_DEBUG=context EGL_DEBUG=verbose
> run-minibrowser --wpe

Can you retry this command but setting EGL_PLATFORM=drm ?

On my laptop setting EGL_PLATFORM=wayland makes dyz to not work (no window appears anywhere)

[Michael Catanzaro]

I still only get "PlatformDisplayWPE: could not create the EGL display."

[Michael Catanzaro]

Created attachment 327440 [details]
EGLGetDisplay test program

I've been trying to run Carlos's branch of dyz using the fdo backeend... but after making some hacks to try to make it start, all I've been able to do is see it crash. The problem is that the call to EGLGetDisplay() in wlglue.cpp always returns NULL. This is a really hacked up environment, but I suspect it's the same problem that's breaking vanilla dyz following the simple reproducer up above.

I've attached a test program that just calls wl_display_connect, then eglGetDisplay, then prints the results. It works just fine on Fedora 27 outside of the WebKit JHBuild environment:

$ gcc `pkg-config --cflags --libs wayland-egl egl` eglgetdisplaytest.c
$ ./a.out
wayland_display=0x24dddd0
egl_display=0x24ea6a0

But inside the JHBuild environment, EGLGetDisplay always fails:

$ Tools/jhbuild/jhbuild-wrapper --wpe run gcc `pkg-config --cflags --libs wayland-egl egl` eglgetdisplaytest.c
$ Tools/jhbuild/jhbuild-wrapper --wpe run ./a.out
wayland_display=0xcf8dd0
egl_display=(nil)

I conclude that EGL does not work inside the WPE JHBuild environment.

[Carlos Garcia Campos]

Could you try building a newer mesa version in the jhbuild. It's something I has in my TODO, because I think newer mesa supports swrast in wayland, so we won't need a real display to run the tests in wayland bot anymore.

[Carlos Alberto Lopez Perez]

(In reply to Carlos Garcia Campos from comment #24)
> Could you try building a newer mesa version in the jhbuild. It's something I
> has in my TODO, because I think newer mesa supports swrast in wayland, so we
> won't need a real display to run the tests in wayland bot anymore.

Notice this is WPE.. WPE doesn't build Mesa. It just assumes you have a GPU with mesa-based drivers (that can be used with GBM).

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #23)

> But inside the JHBuild environment, EGLGetDisplay always fails:
> 
> $ Tools/jhbuild/jhbuild-wrapper --wpe run gcc `pkg-config --cflags --libs
> wayland-egl egl` eglgetdisplaytest.c
> $ Tools/jhbuild/jhbuild-wrapper --wpe run ./a.out
> wayland_display=0xcf8dd0
> egl_display=(nil)
> 
> I conclude that EGL does not work inside the WPE JHBuild environment.

Can you try to remove the wayland stuff from the WPE JHBuild moduleset and rebuild? It may be the cause.
It looks we are building there wayland-1.10 (and it doesn't have a <pkg-config> entry so it will build unconditionally even if you have newer wayland :( )

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #26)
> Can you try to remove the wayland stuff from the WPE JHBuild moduleset and
> rebuild? It may be the cause.
> It looks we are building there wayland-1.10 (and it doesn't have a
> <pkg-config> entry so it will build unconditionally even if you have newer
> wayland :( )

Yeah, I'll try that first. If that doesn't solve it, I'll do a "bisect" of the moduleset by removing different sets of modules until I figure out what's causing it.

(In reply to Carlos Garcia Campos from comment #24)
> Could you try building a newer mesa version in the jhbuild. It's something I
> has in my TODO, because I think newer mesa supports swrast in wayland, so we
> won't need a real display to run the tests in wayland bot anymore.

I have mesa 17.2.4-2.fc27. The only newer version is 17.2.5. I doubt building that would help. I was thinking I might need to build an *older* mesa, because perhaps WPE only worked with older mesa, until I realized that EGLGetDisplay did not work at all inside the WPE JHBuild.

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #26)
> Can you try to remove the wayland stuff from the WPE JHBuild moduleset and
> rebuild? It may be the cause.
> It looks we are building there wayland-1.10 (and it doesn't have a
> <pkg-config> entry so it will build unconditionally even if you have newer
> wayland :( )

Yup, that's definitely the cause. Weird.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #28)
> (In reply to Carlos Alberto Lopez Perez from comment #26)
> > Can you try to remove the wayland stuff from the WPE JHBuild moduleset and
> > rebuild? It may be the cause.
> > It looks we are building there wayland-1.10 (and it doesn't have a
> > <pkg-config> entry so it will build unconditionally even if you have newer
> > wayland :( )
> 
> Yup, that's definitely the cause. Weird.

I got it to display a window! Wheee!

I will create a new bug to upgrade Wayland. And for making the changes needed to build and run dyz-fdo.

Next problem. The window is completely white, and it hits this assertion right away:

ASSERTION FAILED: !RunLoop::isMain()
../../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp(378) : void WebKit::ThreadedCompositor::frameComplete()

I'll try to debug that now, but my odds of fixing anything that says ThreadedCompositor are not very great.

[Michael Catanzaro]

Ignoring that crash for now... next problem. I'm now using the fdo backend, including Carlos's fdo-glib-api branch of dyz. I've done the following work:

 * Changed the JHBuild moduleset to build wpe-fdo (in addition to wpe-mesa, for now) and Carlos's fdo-glib-api branch of dyz
 * Manually deleted the WPEBackend-default.so symlink and replaced it with a copy of WPEBackend-fdo.so

Now, to launch dyz, I have to run this arcana (from the toplevel WebKit directory):

$ Tools/jhbuild/jhbuild-wrapper --wpe run WebKitBuild/DependenciesWPE/Source/dyz/launch -b $(pwd)/WebKitBuild/Debug

That works.

But this does not work:

$ run-minibrowser --wpe --debug
Starting dyz 
dyz: error while loading shared libraries: libwlglue.so: cannot open shared object file: No such file or directory

So that's not good: dyz depends on an internal shared object that is not installed. libwlglue ought to be a static library instead, or installed and renamed. For a quick workaround, I'll modify the install target of dyz/src/Makefile:

install: dyz
	mkdir -p $(DESTDIR)$(BINDIR)
	install -m755 -t $(DESTDIR)$(BINDIR) dyz

to:

install: dyz
	mkdir -p $(DESTDIR)$(BINDIR)
	mkdir -p $(DESTDIR)$(LIBDIR)
	install -m755 -t $(DESTDIR)$(BINDIR) dyz
	install -m755 -t $(DESTDIR)$(LIBDIR) libwlglue.so

Now that avoids the linker error, but I still see a Lua error:

$ run-minibrowser --wpe --debug
Starting dyz 
apps/singleview/main.lua:7: module 'lib.wpebackend_fdo' not found:
	no field package.preload['lib.wpebackend_fdo']
	no file './lib/wpebackend_fdo.lua'
	no file '/usr/share/luajit-2.1.0-beta3/lib/wpebackend_fdo.lua'
	no file '/usr/local/share/lua/5.1/lib/wpebackend_fdo.lua'
	no file '/usr/local/share/lua/5.1/lib/wpebackend_fdo/init.lua'
	no file '/usr/share/lua/5.1/lib/wpebackend_fdo.lua'
	no file '/usr/share/lua/5.1/lib/wpebackend_fdo/init.lua'
	no file './lib/wpebackend_fdo.so'
	no file '/usr/local/lib/lua/5.1/lib/wpebackend_fdo.so'
	no file '/usr/lib64/lua/5.1/lib/wpebackend_fdo.so'
	no file '/usr/local/lib/lua/5.1/loadall.so'
	no file './lib.so'
	no file '/usr/local/lib/lua/5.1/lib.so'
	no file '/usr/lib64/lua/5.1/lib.so'
	no file '/usr/local/lib/lua/5.1/loadall.so'

I presume this is an issue with LUA_PATH. Indeed, I can fix it with this hack:

$ LUA_PATH=WebKitBuild/DependenciesWPE/Source/dyz/src/?.lua run-minibrowser --wpe --debug

That works to start a white WPE window (white due to bug #179957). It's not clear to me why that's required only for the fdo branch of dyz and not the master branch.

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #29)
> 
> I will create a new bug to upgrade Wayland. 

Maybe is a better idea to just remove wayland from the moduleset and add the dev packages to the script install-dependencies?
 
My experience with this is that building for a different version of Wayland than the one that will be used by the compositor at run-time usually causes issues.

On the GTK+ port JHBuild moduleset we only build wayland and weston _if_ the system wayland is not new enough (via <pkg-config> entries), otherwise we use the one from the system. That is required because the GTK+ default build relies on wayland, and we want to support building on systems that don't have new enough wayland.

However the WPE port is different, one one hand the build doesn't depend directly on Wayland directly (it depends on which backend you will use), on the other hand the layout tests currently run headless using the surfaceless/GBM EGL platform, so I don't think the version of Wayland will affect the output of them in any case.

My vote is to just remove it and rely on the system wayland.

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #31)
> (In reply to Michael Catanzaro from comment #29)
> > 
> > I will create a new bug to upgrade Wayland. 
> 
> Maybe is a better idea to just remove wayland from the moduleset and add the
> dev packages to the script install-dependencies?

See bug #179951. That's the first patch there.

(In reply to Carlos Alberto Lopez Perez from comment #31)
> My experience with this is that building for a different version of Wayland
> than the one that will be used by the compositor at run-time usually causes
> issues.

Then this is going to be a hard problem, because we need it in the JHBuild moduleset for WebGL tests, but we also need it to not be in the moduleset for it to do anything. Anyway, please leave a comment in bug #179951... we can discuss it there.

[Zan Dobersek]

I don't know what value this still has, or what value it will have in the future, but resolving this successfully probably depends on bug #184357.

[Michael Catanzaro]

(In reply to Zan Dobersek from comment #33)
> I don't know what value this still has, or what value it will have in the
> future, but resolving this successfully probably depends on bug #184357.

My proposed release criteria:

$ Tools/wpe/install-dependencies
$ update-webkitwpe-libs
$ build-webkit --wpe
$ run-minibrowser --wpe

ought to show work and show some web content.

[Carlos Alberto Lopez Perez]

(In reply to Michael Catanzaro from comment #34)
> (In reply to Zan Dobersek from comment #33)
> > I don't know what value this still has, or what value it will have in the
> > future, but resolving this successfully probably depends on bug #184357.
> 
> My proposed release criteria:
> 
> $ Tools/wpe/install-dependencies
> $ update-webkitwpe-libs
> $ build-webkit --wpe
> $ run-minibrowser --wpe
> 
> ought to show work and show some web content.

This is explained here https://trac.webkit.org/wiki/WPE included a workaround for people using X11 (as dyz currently needs wayland).

Have you tested this with fdo that landed yesterday?

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #35)
> Have you tested this with fdo that landed yesterday?

Not yet, I haven't tried it since November

[Michael Catanzaro]

Testing testing:

$ run-minibrowser --wpe --debug
Starting dyz 
xkbcommon: ERROR: failed to add default include path /home/mcatanzaro/Projects/WebKit/WebKitBuild/DependenciesWPE/Root/share/X11/xkb
Segmentation fault (core dumped)

I fixed that a week ago in bug #184388.

[Michael Catanzaro]

Works for me with the patch in bug #184388 included.