Raspberry Pi 4: Garbled output to monitor with COG_PLATFORM_FDO_VIEW_FULLSCREEN

[nemosupremo]

Hardware

• Raspberry Pi 4

Software

• cog 0.4.0
• WPEWebkit 2.26.1
• WPEBackend-fdo 1.4.0.1
• libwpe 1.4.0.1

Command

$ COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 cog -P fdo https://google.com 

Output

Notes

Non-fullscreen works fine. Taking a screenshot also returns correct output.

[nemosupremo]

Another image:

It looks like there are 30 identical vertical stripes, each 64px wide. I can't really tell whats going on horizontally though.

[nemosupremo]

The following diff fixes the issue for me:

diff --git a/platform/cog-platform-fdo.c b/platform/cog-platform-fdo.c
index 7ecb872..b94b6a4 100644
--- a/platform/cog-platform-fdo.c
+++ b/platform/cog-platform-fdo.c
@@ -1169,7 +1169,8 @@ on_export_fdo_egl_image(void *data, struct wpe_fdo_egl_exported_image *image)
 {
     wpe_view_data.image = image;

-    if (win_data.is_fullscreen) {
+    if (win_data.is_fullscreen && 0) {
       struct wl_region *region;
       region = wl_compositor_create_region (wl_data.compositor);
       wl_region_add (region, 0, 0, win_data.width, win_data.height);

However, I don't know why. Basically the special path in on_export_fdo_egl_image for is_fullscreen does something "wrong" - but I don't know enough about wayland/opengl to know.

Edit: The issue also doesn't occur if the opaque region is set to width < 1920 && height < 1080.

[nemosupremo]

simple-egl uses the same technique to mark the window as opaque in fullscreen mode. However, this doesn't cause the same issue.

[philn]

What's your weston version?

[fooishbar]

Also, export_fdo_egl_image gives me the shudders. Are you using the Mesa EGL dmabuf export extension?

Import is totally fine, but export is known-broken for modifiers: it always reports 0 which is DRM_FORMAT_MOD_LINEAR. RPi will use its tiling format even if you don't request it. What happens if you pretend that no modifier was present (i.e. DRM_FORMAT_MOD_INVALID), or just hack it to force the BCM T_TILED format?

[philn]

The EGLImage is created from the DMABuf with eglCreateImageKHR() : https://github.com/Igalia/WPEBackend-fdo/blob/master/src/ws.cpp#L416

[nemosupremo]

Weston 5.0.0

https://packages.debian.org/buster/weston

[fooishbar]

Ah, that version of Weston is known to have problems with modifiers. Could you please try with 7.0.0?

[nemosupremo]

Same issue with weston 7.0.0 unfortunately.

What happens if you pretend that no modifier was present (i.e. DRM_FORMAT_MOD_INVALID), or just hack it to force the BCM T_TILED format?

Is this a change I can try cog? Or in WPEBackend-fdo? Also not entirely sure why this only occurs when the region is marked as opaque.

[philn]

That change shouldn't be needed i think. Can you try a more recent version of Weston first, please?

[nemosupremo]

I believe the most recent version is 7.0.0?

[philn]

It is indeed.

[fooishbar]

Also not entirely sure why this only occurs when the region is marked as opaque.

Weston will only promote opaque views (surfaces) to hardware planes. If it's alpha-transparent, we will always composite through the GPU. So it's a change between EGL/GLES (format with alpha) and KMS (opaque format).

[nemosupremo]

I don't think the Pi4 supports the DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED format. The Pi 4's GPU is the VC6 - and in my feeble attempt at forcing I ended up crashing cog with "modifier not supported"

[nemosupremo]

Ok, I think the modifier is actually being exported as DRM_FORMAT_MOD_BROADCOM_UIF (0x700000000000006) Forcing this to DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED causes Attempt to import unsupported modifier 0x700000000000001.

[WebReflection]

Same issue here, which was driving me crazy!

as soon as I've removed COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 I could see what I've been waiting to see for long time ... everything was fine!

I'm on ArchLinux, and I've pre-built wpewebkit-gl-$(uname -m) (both armv7l and aarch64) using cairo-glesv2-$(uname -m) module, so that weston, as well as everything else around that doesn't come from AUR, is the latest version available.

I wouldn't mind low down the resolution, but from the little documentation I've read, there's no way to specify a resolution in COG, is that correct?

[philn]

You can set these env vars, COG_PLATFORM_FDO_VIEW_WIDTH=<integer> and COG_PLATFORM_FDO_VIEW_HEIGHT=<integer>.

[WebReflection]

right, that worked, however I'm in a loop:

• I can't force Weston to change resolution
• if I use Xorg, I can change resolution and launch Weston with xwayland (or without it, it's the same)
• if I launch cog from weston, after xinit, nothing works, not even if I specify the socket and the WAYLAND_DISPLAY

In few words: is this going to be solved any time soon, or should I try something else? TinyWL didn't work neither, so I can't grant a full screen experience, even scaling down, with cog, which is a bummer.

Thanks for help and hints.

[nemosupremo]

If you set COG_PLATFORM_FDO_VIEW_WIDTH and COG_PLATFORM_FDO_VIEW_HEIGHT to your output's resolution, you will trigger this bug as well; so that work around doesn't really help.

1. What we ended up doing was was forking cog disabling opaque region optimizations (as mentioned in https://github.com/Igalia/cog/issues/156#issuecomment-544206920). There is a performance hit, but for our use case, it was ok.

2. We are using weston exclusively - you can force a specific resolution for weston via weston.ini, although I'm unsure if you can change it on the fly.

[philn]

Which Mesa version are you guys using?

[WebReflection]

thanks @nemosupremo , but that fix looks to me like an if (false && whatever) ... so I didn't think about applying the same fix, although, about weston, adding [output] section with a mode=1280x720 produced exactly zero results, starting from a regular terminal login.

Do you have any precise hint on how to tell weston to enforce a different resolution?

[WebReflection]

@philn 19.3.2 here, once again, ArchLinux, the latest, the greatest :-)

[philn]

@WebReflection on RPi as well as @nemosupremo ?

[philn]

BTW if you don't need Weston and want a full-screen kiosk-like browser, you could try the DRM plugin, cog -P drm-experimental <url>

[WebReflection]

@philn I have RPi4 which uses 32bit ArchLinux but it has that version, but also RPi3 which uses 64bit ArchLinux, and it has that version. All running smoothly, except for this bit (well, RPi3 on 64bit cannot even start weston anymore, but that's another story, I'm testing RPi4 here)

[WebReflection]

@philn that gives me a "cannot open libcogplatform-drm.so" message, failing through libWPEBackend-default.so

[WebReflection]

@philn also please note I'm maintaining https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cog-wpe-gl so if there's anything else I should enable in that build, please let me know, 'cause bypassing weston as a whole from a regular terminal (login) would be even more awesome!

[philn]

Sorry, I meant drm-experimental I edited the comment after realising.

[philn]

And you'd need to enable a CMake option indeed, https://github.com/Igalia/cog/blob/master/CMakeLists.txt#L59 The DRM plugin wasn't shipped in 0.4.x I think, but a 0.5.x should be released soon hopefully.

[WebReflection]

The DRM plugin wasn't shipped in 0.4.x I think, but a 0.5.x should be released soon hopefully.

any ETA on that?

[philn]

@aperezdc is managing the releases :) I think the plan is to have a RC 0.5 in the coming days, though there's a few PRs to merge first.

[nemosupremo]

@WebReflection Setting the resolution is kind of weird in weston, you have to set the output name for it take effect.

[output]
name=HDMI-A-1
mode=preferred # or mode=1280x720

@philn We are using the Debian Buster provided libraries, so 18.3.6-2

I'm pretty sure this issue is an RPi issue with the driver/gpu/whatever not supporting the RPi4's tilting format

[WebReflection]

@nemosupremo wow, I didn't know about it, and then again it makes sense, as [output] can be configured more than once (but I'd expect it to use the first live monitor/TV if none is provided...)

Anyway, as the Pi4 has two HDMI, I wonder if this live/runtime patch makes sense, considering I have only one name= in my weston.ini

setMode() {
  local MODE="$1"
  local NAME="$(ls /sys/class/drm | grep HDMI)"
  sed -i "s/name=.*/name=${NAME:6}/;s/mode=.*/mode=${MODE}/" ~/.config/weston.ini
}

Do you think setMode '1280x720' on bootstrap makes sense? I might reuse the same for RPi3 once I manage to make it work.

Also apologies for going a bit off topic, I'm just super happy I've managed to use cog on weston and Pi4 ... it also looks like the --socket argument is not needed anymore, which is nice!

[WebReflection]

FYI this is how my Pi4 currently boot: jellyfish demo at almost 60FPS https://youtu.be/T3BdiEe8lqA

[WebReflection]

Just FYI, I can confirm even at 720p if I use COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 instead of COG_PLATFORM_FDO_VIEW_WIDTH=1280 COG_PLATFORM_FDO_VIEW_HEIGHT=720 the screen is zebra/striped as if it was Full HD.

[zdobersek]

Reproducible with Zeus branches of various Yocto layers, Weston 7.0.0.

The issue can be avoided if the wl_surface.set_opaque_region() call is disabled here: https://github.com/Igalia/cog/blob/master/platform/cog-platform-fdo.c#L1172

The call is there for a reason, it's intended to hint to Weston that this content can be displayed more efficiently when in fullscreen. Unclear what trips up Weston to mis-render it, and who's to blame.

[fooishbar]

If the region is not marked opaque, Weston will use GLES to render the final content to screen. If the region is marked opaque, Weston will try to display it directly to KMS.

Usually a mismatch in modifiers is to blame. It would be good to get the output of running weston-debug proto drm-backend when having started with weston --debug when this bug is triggering.

[zdobersek]

Issue is also reproducible with the drm backend, with the same garbled output visible.

The modifiers are respected, with DRM_FORMAT_MOD_BROADCOM_UIF being used. This turns problematic when the dmabuf resource is displayed on any plane, since the planes only support MOD_LINEAR and in some cases MOD_BROADCOM_VC4_T_TILED. As such, the resource using MOD_BROADCOM_UIF is mis-represented, and the garbled output ensues.

[fooishbar]

If the plane doesn't actually support UIF but it accepts a buffer explicitly declared as UIF then the KMS driver is buggy. Can someone please attach the weston-debug output? That should make it clear.

[zdobersek]

Here's weston-debug output, as well as output of modetest and dumps of the framebuffer and DRM state: https://gist.github.com/zdobersek/b72c2f56b4a6180dd4ede60043d193d5

[WebReflection]

it looks like cog crashes with weston 8, which landed in ArchLinux, and nothing works anymore, not even zebra, just crashes. Could this be related? Apologies if not.

[zdobersek]

it looks like cog crashes with weston 8, which landed in ArchLinux, and nothing works anymore, not even zebra, just crashes. Could this be related? Apologies if not.

Probably not, but I guess it signals a different problem.

[WebReflection]

We can close this, current cog 0.6 works in fullscreen via fdo (but it doesn't work with the drm target at all in the Raspberry Pi 4, I guess that's another issue).

[aperezdc]

We can close this, current cog 0.6 works in fullscreen via fdo (but it doesn't work with the drm target at all in the Raspberry Pi 4, I guess that's another issue).

Thanks for the heads up—and yes, I agree that the issue with the DRM platform plug-in we can take care of it in a separate issue, thanks for filing it.

@nemosupremo Could you confirm that Cog 0.6 + WPE WebKit 2.28.0 + WPEBackend-fdo 1.6.0 + libwpe 1.6.0 also works for you before we close this?

[nemosupremo]

Yep, I started rebuilding my stack when I got @WebReflection email. WPEWebkit takes like 6 hours to build so I should know in a couple hours.

[WebReflection]

OK, I can confirm FDO in fullscreen and full HD has no issues anymore.

[WebReflection]

@nemosupremo if you're on ArchLinux I've created wpewebkit-gl-$(uname -m) which is pre built for both pi3 and pi4.

It uses cairo-glesv2-$(uname -m) to have hw accelerated render

[nemosupremo]

Unfortunately I still get tiled output :(

$ WEBKIT_SHOW_FPS=1 COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 LD_LIBRARY_PATH=/usr/local/lib cog --version               
0.6.0 (WPE WebKit 2.28.0)
$ WEBKIT_SHOW_FPS=1 COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 LD_LIBRARY_PATH=/usr/local/lib cog -P fdo http://github.com

@WebReflection

I'm on Raspbian. What version of weston are you using? What is in your /boot/config.txt? Do you remember what CMake options you used?

[nemosupremo]

Unrelated; if I apply my previous fix that disables the opaque region, the updated stack works alot better on the Pi 4. I can smoothly seek through videos, and videos that were once choppy are no longer choppy at all.

[WebReflection]

@nemosupremo I build cairo-glesv2 like this and wpewebkit like that.

Weston is 8.0.3 IIRC, ArchLinux is always on latest version available.