Starting cog on i.MX6 board has no visible effect
vnd opened this issue · comments
I'm trying to start cog on a custom i.MX6DL board using Yocto dunfell, but the requested page is not actually displayed. I've tried both fdo and rdk/wayland backends.
local.conf
IMX_DEFAULT_BSP = "nxp" (so gpu-viv is used)
PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk"
PACKAGECONFIG_pn-wpebackend-rdk = "wayland"
# OR for fdo:
# PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-fdo"
Relevant layers:
- meta-freescale from 'Freescale' github
- meta-webkit from Igalia, both dunfell.
Component versions:
cog 0.8.1
wayland 1.18.0
weston 8.0.0.imx
wpewebkit 2.32.1
wpebackend-rdk 1.20200213
Scenario
export XDG_RUNTIME_DIR=/run
/usr/bin/cog -P fdo https://google.com # for fdo backend
/usr/bin/cog https://google.com # for rdk backend
Console output:
Cog-Message: 05:43:20.664: <https://google.com/> Load started.
Cog-Message: 05:43:20.704: <https://www.google.com/> Redirected.
Cog-Message: 05:43:21.909: <https://www.google.com/> Loading...
Cog-Message: 05:43:30.736: <https://www.google.com/> Loaded successfully.
With FDO backend, the above is also preceded by:
error marshalling arguments for enable_tile_status (signature ouuuuu): null value passed for arg 0
Error marshalling request: Invalid argument
And the problem is, there's nothing resembling browser or google.com page seen on the screen, there's just empty Weston "desktop". It's likely that I'm missing something obvious, since it's the first time I'm trying to use cog (need to port old Yocto krogoth build that uses deprecated WPELauncher), but I've tried what I could find and pretty much stuck at this point.
RDK backend with debug messages:
(cog:2145): GLib-DEBUG: 08:46:17.059: posix_spawn avoided (child_setup specified)
** (cog:2145): DEBUG: 08:46:17.133: platform_setup: Platform name: (null)
** (cog:2145): DEBUG: 08:46:17.134: Instantiating default WPE backend as fall-back.
(cog:2145): GLib-DEBUG: 08:46:17.258: posix_spawn avoided (child_setup specified)
(process:2197): GLib-GIO-DEBUG: 08:46:17.986: Failed to initialize portal (GNetworkMonitorPortal) for gi
o-network-monitor: Not using portals
(process:2197): GLib-GIO-DEBUG: 08:46:18.019: Failed to initialize networkmanager (GNetworkMonitorNM) fo
r gio-network-monitor: NetworkManager not running
(process:2197): GLib-GIO-DEBUG: 08:46:18.021: _g_io_module_get_default: Found default implementation net
link (GNetworkMonitorNetlink) for ?gio-network-monitor?
(process:2197): GLib-GIO-DEBUG: 08:46:18.036: _g_io_module_get_default: Found default implementation loc
al (GLocalVfs) for ?gio-vfs?
Cog-Message: 08:46:19.693: <https://google.com/> Load started.
Cog-Message: 08:46:19.819: <https://www.google.com/> Redirected.
(process:2197): GLib-GIO-DEBUG: 08:46:19.972: _g_io_module_get_default: Found default implementation gnu
tls (GTlsBackendGnutls) for ?gio-tls-backend?
(process:2197): GLib-GIO-DEBUG: 08:46:20.007: _g_io_module_get_default: Found default implementation dum
my (GDummyProxyResolver) for ?gio-proxy-resolver?
(process:2197): GLib-GIO-DEBUG: 08:46:20.220: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:20.288: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:20.289: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:20.310: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:20.310: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:20.311: GSocketClient: Connection successful!
(WPEWebProcess:2198): GLib-GIO-DEBUG: 08:46:20.897: _g_io_module_get_default: Found default implementati
on gnutls (GTlsBackendGnutls) for ?gio-tls-backend?
(cog:2145): GLib-GIO-DEBUG: 08:46:21.004: _g_io_module_get_default: Found default implementation gnutls
(GTlsBackendGnutls) for ?gio-tls-backend?
Cog-Message: 08:46:21.098: <https://www.google.com/> Loading...
(process:2197): GLib-GIO-DEBUG: 08:46:23.099: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:23.101: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:23.101: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:23.123: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:23.123: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:23.123: GSocketClient: Connection successful!
(process:2197): GLib-GIO-DEBUG: 08:46:28.159: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:28.160: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:28.161: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:28.180: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:28.181: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:28.181: GSocketClient: Connection successful!
(process:2197): GLib-GIO-DEBUG: 08:46:28.651: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:28.680: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:28.688: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:28.688: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:28.692: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:28.692: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:28.706: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:28.706: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:28.706: GSocketClient: Connection successful!
(process:2197): GLib-GIO-DEBUG: 08:46:28.710: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:28.710: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:28.710: GSocketClient: Connection successful!
(process:2197): GLib-GIO-DEBUG: 08:46:29.376: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:29.433: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:29.434: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:29.466: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:29.467: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:29.468: GSocketClient: Connection successful!
(process:2197): GLib-GIO-DEBUG: 08:46:29.754: GSocketClient: Starting new address enumeration
(process:2197): GLib-GIO-DEBUG: 08:46:29.797: GSocketClient: Address enumeration succeeded
(process:2197): GLib-GIO-DEBUG: 08:46:29.798: GSocketClient: Starting TCP connection attempt
(process:2197): GLib-GIO-DEBUG: 08:46:29.832: GSocketClient: TCP connection successful
(process:2197): GLib-GIO-DEBUG: 08:46:29.832: GSocketClient: Starting application layer connection
(process:2197): GLib-GIO-DEBUG: 08:46:29.833: GSocketClient: Connection successful!
Cog-Message: 08:46:30.289: <https://www.google.com/> Loaded successfully.
^C** (cog:2145): DEBUG: 08:48:48.420: on_shutdown: Platform = (nil)
For the case of wayland, you need to define the XDG_RUNTIME_DIR WAYLAND_DISPLAY with the right values. Something like this could help you:
export $(cat /proc/$(pidof /usr/libexec/weston-keyboard)/environ | strings | grep XDG_RUNTIME_DIR)
export $(cat /proc/$(pidof /usr/libexec/weston-keyboard)/environ | strings | grep WAYLAND_DISPLAY)
bin/cog -P fdo http://wpewebkit.org"
Also notice that the platform is now called wl for the latest versions of Cog: cog -P wl ...
Thank you for the reply!
weston-keyboard is not running, probably b/c of absence of keyboard (with verbose error messages in the log), so I've used 'weston-desktop-shell' instead for checking. Environment variables are set as follows:
export XDG_RUNTIME_DIR=/run
export WAYLAND_DISPLAY=wayland-0
For both weston-desktop-shell, and when starting cog.
In my version of cog (0.8.1), 'wl' platform is not yet recognized, so I'm using 'fdo' with FDO backend.
Note: since board is currently remote, I'm using 'weston-screenshooter' to check if there's something displayed (which also requires settings XDG_RUNTIME_DIR), and it shows demo wayland applications, but nothing for cog.
Could you try with meta-webkit master? It is also compatible with dunfell https://github.com/Igalia/meta-webkit/blob/master/conf/layer.conf#L20 but better maintained.
also set the PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-fdo" if you want to use cog -P wl (it should be wl this time since cog recipe is 0.12 for main/master)
cog from master requires virtual/libgbm, however it looks like imx-gpu-viv provides it only for i.MX8, but we're using i.MX6. Does it mean that mainline BSP (etnaviv + mesa) has to be used for cog on i.MX6, or? I'm not too familiar with Linux graphics stack, so not sure..
On a related note, which one (etnaviv vs imx-gpu-viv) is better/recommended these days?
In the meantime, I'm trying open-source stack, but can't even start weston:
sh-5.0# weston-launch
weston: weston-launch must be run from a virtual terminal
sh-5.0# weston-launch --tty=1
weston: -t/--tty option requires -u/--user option as well
sh-5.0# weston-launch -t /dev/tty1 -u wtf
weston: -u is unsupported in this weston-launch build
sh-5.0# weston --tty=1
Date: 2022-06-02 UTC
[05:45:32.287] weston 8.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 8.0.0
[05:45:32.288] Command line: weston --tty=1
[05:45:32.288] OS: Linux, 5.4.114+, #1 SMP PREEMPT Wed Jun 1 15:36:44 UTC 2022, armv7l
[05:45:32.288] warning: XDG_RUNTIME_DIR "/run" is not configured
correctly. Unix access mode must be 0700 (current mode is 755),
and must be owned by the user (current owner is UID 0).
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
[05:45:32.291] Using config file '/etc/xdg/weston/weston.ini'
[05:45:32.293] Output repaint window is 7 ms maximum.
[05:45:32.299] Loading module '/usr/lib/libweston-8/drm-backend.so'
[05:45:32.318] initializing drm backend
[05:45:32.521] no drm device found
[05:45:32.521] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
sh-5.0# ls /dev/dri/
by-path card0 renderD128
sh-5.0# dmesg|grep etna
[ 1.539131] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
[ 1.545021] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[ 1.550650] etnaviv-gpu 130000.gpu: model: GC880, revision: 5106
[ 1.557041] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[ 1.563886] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
In the meantime, I'm trying open-source stack, but can't even start weston:
[...] sh-5.0# ls /dev/dri/ by-path card0 renderD128 sh-5.0# dmesg|grep etna [ 1.539131] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) [ 1.545021] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) [ 1.550650] etnaviv-gpu 130000.gpu: model: GC880, revision: 5106 [ 1.557041] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [ 1.563886] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0
You're missing /dev/dri/card1 which is the IPU (imx-drm).
Maybe some missing kernel config. You can check and compare your kernel config against this (Wandboard iMX6 QuadCore using etnaviv):
processor : 3
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 7.54
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
Hardware : Freescale i.MX6 Quad/DualLite (Device Tree)
Revision : 0000
Serial : 0000000000000000
root@wandboard-mesa:~# zcat /proc/config.gz | grep DRM | grep -E "DRM=|IMX|ETNAVIV"
CONFIG_DRM=y
CONFIG_DRM_IMX=y
CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
CONFIG_DRM_IMX_TVE=y
CONFIG_DRM_IMX_LDB=y
CONFIG_DRM_IMX_HDMI=y
CONFIG_DRM_ETNAVIV=y
CONFIG_DRM_ETNAVIV_THERMAL=y
Full config settings here: https://paste.debian.net/plain/1242822
On a related note, which one (etnaviv vs imx-gpu-viv) is better/recommended these days?
My personal experience is there is not a huge difference nowadays. Ref: https://www.phoronix.com/scan.php?page=news_item&px=Etnaviv-2020-Driver-Progress
if you can get cog from main branch running, that should work with etnaviv on imx6 with either wayland or drm backends (drm backend needs -O renderer=gles and will get you best performance)
(note that the default modeset renderer in cog/drm does not work)
meta-webkit from master works, so there's apparently something wrong in dunfell revision on i.MX6. And it's not cog-specific, as we have small Qt wrapper around qtwebkit, and it exhibited the same behavior on dunfell.
A bit more details: I'm still using proprietary stack (gpu-viv et al.), the only thing is that I had to change is to explicitly specify wayland packageconfig. Otherwise it tried to build DRM plugin by default, for which there's no libgbm available.
Thanks everyone for the support!