Chromium within Weston / Wayland

[schmi85]

Hello Everybody,

I am using a Raspberry PI 3+ B and I have flashed an SD Card a described here, using the »AArch64 Installation«.

After login I have installed these packages:

- wayland
- weston
- xorg-server-xwayland
- chromium

and tweaked /boot/config.txt, such that it looks like this:

$this->bbcode_second_pass_code('', '
#was already in
enable_uart=1

#those lines are those I have added
dtoverlay=vc4-kms-v3d
avoid_warnings=2
hdmi_drive=2
')

As the »regular« user Alarm, this command issuing this command:

$this->bbcode_second_pass_code('', '
weston --log=weston.log --no-config --xwayland --use-pixman
')

Starts the Desktop and everything is running stable, but very slow, since the GPU is not used. That means: If I open a terminal window and type: chromium, the browser appears and works.

Running
$this->bbcode_second_pass_code('', '
weston --log=weston.log --no-config --xwayland
')

Starts a Desktop as well, but trying to start chromium results in a kind of nothing and the Desktop freezes. I am pretty sure that there is something wrong with the VC4 Driver, or its configuration.

$this->bbcode_second_pass_code('', '
lsmod

Module Size Used by
rc_cec 16384 0
btsdio 20480 0
vc4 192512 4
brcmfmac 303104 0
cec 65536 1 vc4
brcmutil 16384 1 brcmfmac
rc_core 57344 3 rc_cec,cec
drm_kms_helper 200704 3 vc4
hci_uart 131072 0
drm 503808 3 drm_kms_helper,vc4
joydev 28672 0
btqca 20480 1 hci_uart
cfg80211 729088 1 brcmfmac
btbcm 16384 1 hci_uart
microchip 16384 1
btintel 32768 1 hci_uart
drm_panel_orientation_quirks 16384 1 drm
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
bluetooth 593920 6 btqca,btsdio,btintel,hci_uart,btbcm
sysimgblt 16384 1 drm_kms_helper
lan78xx 61440 0
fb_sys_fops 16384 1 drm_kms_helper
ecdh_generic 24576 1 bluetooth
raspberrypi_hwmon 16384 0
rfkill 32768 3 bluetooth,cfg80211
i2c_bcm2835 20480 0
pwm_bcm2835 16384 0
bcm2835_thermal 16384 0
bcm2835_wdt 16384 0
hid_multitouch 28672 0
')

$this->bbcode_second_pass_code('', '
ls -la /dev/dri/
total 0
drwxr-xr-x 3 root root 100 Dec 20 01:38 .
drwxr-xr-x 18 root root 3200 Jan 2 12:38 ..
drwxr-xr-x 2 root root 80 Dec 20 01:38 by-path
crw-rw----+ 1 root video 226, 0 Jan 2 12:38 card0
crw-rw-rw- 1 root render 226, 128 Dec 20 01:38 renderD128
')

$this->bbcode_second_pass_code('', '
#log without --use-pixman
cat weston.log

Date: 2019-01-02 UTC
[13:00:58.164] weston 5.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: unknown (not built from git or tarball)
[13:00:58.165] Command line: weston --log=weston.log --xwayland --no-config
[13:00:58.165] OS: Linux, 4.20.0-2-ARCH, #1 SMP Fri Dec 28 19:33:32 MST 2018, aarch64
[13:00:58.165] Starting with no config file.
[13:00:58.165] Output repaint window is 7 ms maximum.
[13:00:58.165] Loading module '/usr/lib/libweston-5/drm-backend.so'
[13:00:58.178] initializing drm backend
[13:00:58.190] logind: session control granted
[13:00:58.203] using /dev/dri/card0
[13:00:58.204] DRM: supports universal planes
[13:00:58.204] DRM: supports atomic modesetting
[13:00:58.204] DRM: supports picture aspect ratio
[13:00:58.207] Loading module '/usr/lib/libweston-5/gl-renderer.so'
[13:00:58.551] EGL client extensions: EGL_EXT_device_base
EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug
EGL_EXT_platform_wayland EGL_EXT_platform_x11
EGL_MESA_platform_gbm EGL_MESA_platform_surfaceless
[13:00:58.555] warning: neither EGL_EXT_swap_buffers_with_damage or EGL_KHR_swap_buffers_with_damage is supported. Performance could be affected.
[13:00:58.555] EGL_KHR_surfaceless_context available
[13:00:58.569] EGL version: 1.4
[13:00:58.569] EGL vendor: Mesa Project
[13:00:58.569] EGL client APIs: OpenGL OpenGL_ES
[13:00:58.569] EGL extensions: EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2
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_colorspace
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 EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context
EGL_MESA_drm_image EGL_MESA_image_dma_buf_export
EGL_WL_bind_wayland_display
[13:00:58.569] GL version: OpenGL ES 2.0 Mesa 18.3.1
[13:00:58.569] GLSL version: OpenGL ES GLSL ES 1.0.16
[13:00:58.569] GL vendor: Broadcom
[13:00:58.569] GL renderer: VC4 V3D 2.1
[13:00:58.570] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_occlusion_query_boolean 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_stencil8
GL_OES_texture_3D GL_OES_texture_npot GL_OES_vertex_half_float
GL_OES_EGL_image GL_OES_depth_texture
GL_AMD_performance_monitor GL_OES_packed_depth_stencil
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_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_texture_compression_astc_ldr
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_separate_shader_objects
GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_MESA_tile_raster_order
[13:00:58.570] GL ES 2 renderer features:
read-back format: BGRA
wl_shm sub-image to texture: yes
EGL Wayland extension: yes
[13:00:58.603] event3 - vc4: is tagged by udev as: Keyboard Mouse
[13:00:58.604] event3 - vc4: device is a pointer
[13:00:58.604] event3 - vc4: device is a keyboard
[13:00:58.619] event1 - CHICONY HP Basic USB Keyboard: is tagged by udev as: Keyboard
[13:00:58.619] event1 - CHICONY HP Basic USB Keyboard: device is a keyboard
[13:00:58.697] event2 - HP HP: is tagged by udev as: Mouse
[13:00:58.697] event2 - HP HP: device is a pointer
[13:00:58.776] event0 - eGalax Inc. eGalaxTouch EXC3188-0085-04.00.00: is tagged by udev as: Touchscreen
[13:00:58.776] event0 - eGalax Inc. eGalaxTouch EXC3188-0085-04.00.00: device is a touch device
[13:00:58.818] Touchscreen - eGalax Inc. eGalaxTouch EXC3188-0085-04.00.00 - /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:0EEF:C000.0001/input/input3/event0
[13:00:58.818] input device event0 has no enabled output associated (none named), skipping calibration for now.
[13:00:58.844] DRM: head 'HDMI-A-1' found, connector 29 is connected, EDID make 'CND', model 'HDMI', serial '000000000000'
[13:00:58.844] DRM: head 'Composite-1' found, connector 44 is disconnected.
[13:00:58.845] Registered plugin API 'weston_drm_output_api_v1' of size 24
[13:00:58.845] Chosen EGL config details:
RGBA bits: 8 8 8 0
swap interval range: 1 - 1
[13:00:58.847] No backlight control for output 'HDMI-A-1'
[13:00:58.847] Output HDMI-A-1 (crtc 95) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
1920x1080@60.0 16:9, 148.5 MHz
1920x1080@59.9 16:9, 148.4 MHz
1920x1080@60.0, 138.5 MHz
1920x1080@60.0, 74.2 MHz
1920x1080@60.0 16:9, 74.2 MHz
1920x1080@59.9 16:9, 74.2 MHz
1920x1080@50.0 16:9, 148.5 MHz
1920x1080@50.0 16:9, 74.2 MHz
1680x1050@59.9, 119.0 MHz
1280x1024@60.0, 108.0 MHz
1440x900@59.9, 88.8 MHz
1280x960@60.0, 108.0 MHz
1366x768@59.8, 85.5 MHz
1280x800@59.9, 71.0 MHz
1280x720@60.0, 74.2 MHz
1280x720@60.0 16:9, 74.2 MHz
1280x720@59.9 16:9, 74.2 MHz
1024x768@60.0, 65.0 MHz
1440x480@60.0 16:9, 54.1 MHz
1440x480@59.9 16:9, 54.0 MHz
800x600@60.3, 40.0 MHz
800x600@56.2, 36.0 MHz
720x576@50.0 4:3, 27.0 MHz
720x480@60.0 4:3, 27.0 MHz
720x480@60.0 16:9, 27.0 MHz
720x480@59.9, 27.0 MHz
720x480@59.9 16:9, 27.0 MHz
720x480@59.9 4:3, 27.0 MHz
640x480@60.0 4:3, 25.2 MHz
640x480@59.9, 25.2 MHz
640x480@59.9 4:3, 25.2 MHz
720x400@70.1, 28.3 MHz
[13:00:58.848] associating input device event3 with output HDMI-A-1 (none by udev)
[13:00:58.848] associating input device event1 with output HDMI-A-1 (none by udev)
[13:00:58.848] associating input device event2 with output HDMI-A-1 (none by udev)
[13:00:58.848] associating input device event0 with output HDMI-A-1 (none by udev)
[13:00:58.849] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
[13:00:58.849] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[13:00:58.850] Loading module '/usr/lib/weston/desktop-shell.so'
[13:00:58.852] launching '/usr/lib/weston/weston-keyboard'
[13:00:58.856] Loading module '/usr/lib/libweston-5/xwayland.so'
[13:00:58.900] Registered plugin API 'weston_xwayland_v1' of size 32
[13:00:58.900] Registered plugin API 'weston_xwayland_surface_v1' of size 16
[13:00:58.901] xserver listening on display :0
[13:00:58.901] launching '/usr/lib/weston/weston-desktop-shell'
[13:01:10.221] Spawned Xwayland server, pid 1024
[13:01:11.447] xfixes version: 5.0
[13:01:11.512] created wm, root 924
[13:01:16.993] xserver exited, code 134
[13:02:26.297] output for input device event3 removed
[13:02:26.298] output for input device event1 removed
[13:02:26.298] output for input device event2 removed
[13:02:26.298] output for input device event0 removed
[13:02:26.315] event3 - vc4: device removed
[13:02:26.315] event1 - CHICONY HP Basic USB Keyboard: device removed
[13:02:26.316] event2 - HP HP: device removed
[13:02:26.317] event0 - eGalax Inc. eGalaxTouch EXC3188-0085-04.00.00: device removed
')

Yields a Segmentation Fault Error on the Commandline after Weston was shutdown by ctrl+alt+backspace.

What may be wrong here?

[summers]

Does Chromium have a wayland interface, and/or does weston have the xwayland enabled?

I know when I first used weston, I didn't use the x extension, and only a handful of programs worked well.

I soon switched to gnome, which did wayland native, and ran the x extensions - as I needed these for firefox and thunderbird. Guess i should check if they yet have direct wayland interfaces. I've found the direct wayland interfaces best, so tend to use programs like "mpv" that are native when I have the choice ...

[schmi85]

By installing xorg-server-xwayland and setting the --xwayland switch when issuing

$this->bbcode_second_pass_code('', '
weston --log=weston.log --no-config --xwayland
')

the xwayland extension is loaded, what can as well been seen in the weston log:

$this->bbcode_second_pass_code('', '
[13:00:58.856] Loading module '/usr/lib/libweston-5/xwayland.so'
')

Furthermore, when launching Arch within a virtual box, not a pi, the same setup yields a running Browser. Setting the --use-pixman switch yields a running browser as well, but that does not use GL, so the performance is poor. My guess is that there is something wrong with the installation of the GL driver. But I really don't know how to track that error, which log to search etc.

[schmi85]

Digging deeper in that… I have added the mesa-demos package, since that includes glxinfo, started a wayland session as above (weston --no-config --xwayland) and ran

$this->bbcode_second_pass_code('', '
glxinfo | grep render
')

what yields:

$this->bbcode_second_pass_code('', '
direct rendering: Yes
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: VC4 V3D 2.1
GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer,
')

But OpenGL renderer string should be something like »Gallium«, so this seams to indicate the mistake more clearly.

[summers]

Wayland doesn't use GL IIRC, it only used GLES.

Problem with GL is it pulled in X dependencies, and the Wayland authors wanted to avoid that ...

@summers Thanks for your reply!

$this->bbcode_second_pass_quote('', '
')Wayland doesn't use GL IIRC, it only used GLES.

[summers]

GL is a library for talking to the GPU so to get acceleration.

GLES is a subset of GL, simpler in set up. It was designed for embedded systems ...

Both libraries are done by Khronos IIRC.

Now as libraries they stand between the GPU and the OS. The linux GL (OpenGL) when developed the linux graphical interface was inevitably X based. So in the library it has interfaces direct through to the X set up.

When wayland was developed, IIRC the author wanted to make sure he had zero dependence on X. It was a new graphic interface, totally separate from X. Easy way to ensure no dependence, was to use GLES, that didn't pull in any X dependencies - so that was how the code was developed. It means that wayland can only use a subset of the OpenGL commands, those that are in OpenGLES. However did prove that Wayland was independent of X.

Now at times, you see talk of doing a WaylandGL library, that does GL without the X dependence - I think its only talked about at the moment, it would be a fair bit of effort - and am not sure that the Wayland authors see this as a priority.

Xwayland is a different issue, when running wayland, most applications don't have an interface through to wayland - they were coded when all that existed was X. But users will want to fun these applications (e.g. firefox). So the wayland authors coded an interface, that took X style inputs, and translated it into wayland talk. Eventually you would hope you wouldn't need to use it - but at the moment its the only way to run many applications. So on an everyday wayland, you practically need to run xwayland; only when testing applications interface to wayland would you switch it off.

When you see how ingrained linux was with the X graphical system, it amazing that the wayland authors decided to do another graphical interface. But they had good reasons, graphics had moved on from X just due to technology evolution. Wayland could be both simpler and also more powerful. The brilliance of the wayland authors is not only could they have such a plan, but that they pulled it off. Going around the linux world, you only find a few of these people, that not only plan major changes, but also have the technical ability to pull it of. So Kristian Høgsberg for Wayland, Chris Mason for btrfs, Rob Landley in the embedded world - all these people are changing the status quo, but in a rigorous way that leads to revolution. I take my hat of to all of them.

You ask about Gallium, from what I recall of the gallium graphic card drivers, I'm reasonably sure these do GLES, or rather OpenGLES can talk directly to Gallium drivers. So yes you definitely want to use a Gallium driver if one is available for your GPU.

Hope this helps.

[schmi85]

Thanks for that detailed explanation and yes, it helped, since now I can say to have a better understanding of the fairly complex linux graphics system, so thanks very much for that!

Since the gallium driver works on/is available for rpi, there at least must be a way to set it up. Simultaneously I think that this certain rabbit-hole turns out to be a bit too deep for me for now. As you said, there seams to be only a handful of people on the planet who actually have the needed knowledge, what kind of explains why it is so hard to find help on that topic.

In case of any further progress on this, I am going to drop the results here.

[summers]

OOps as well as history, guess I should give some help.

On my wayland desk top (arm devices are all headless), $this->bbcode_second_pass_code('', 'glxinfo | grep render') gives $this->bbcode_second_pass_code('', 'direct rendering: Yes
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: AMD PALM (DRM 2.50.0 / 4.19.12-arch1-1-ARCH, LLVM 7.0.0)
GL_ARB_compute_shader, GL_ARB_conditional_render_inverted,
GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,')
So mine doesn't mention gallium either, but my AMD machine is almost certainly Gallium based.

$this->bbcode_second_pass_code('', 'lsmod') gives a huge list - graphics is probably $this->bbcode_second_pass_code('', 'ath9k 184320 0
ath9k_common 36864 1 ath9k
ath9k_hw 507904 2 ath9k_common,ath9k
ath 36864 3 ath9k_common,ath9k,ath9k_hw
radeon 1634304 16
agpgart 49152 2 ttm,drm
')

With the radeon bit, the probably main bit - it doesn't mention gallium - so I guess not all graphics modules mention gallium. Do you know what graphics driver you need to load? Does wayland load it?

On Weston, yes think I also loaded xwayland.so via modules=wayland.so in ~/.config/weston.ini. you can check it working with an x only graphics object, like "xterm".

I would say that, that I only took weston as a reference made by wayland authors, a bit like NCSA Mosaic proved the web could work. So do think about using a display manager that is native wayland and works. When I looked, main one I was happy with was GNOME, usually I go for a simple display manager, but actually GNOME isn't too bad.

@summers Thanks again for your Help!

$this->bbcode_second_pass_quote('', '
')On my wayland desk top (arm devices are all headless),