Closed nemosupremo closed 4 years ago
Another image:
It looks like there are 30 identical vertical stripes, each 64px wide. I can't really tell whats going on horizontally though.
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.
simple-egl uses the same technique to mark the window as opaque in fullscreen mode. However, this doesn't cause the same issue.
What's your weston version?
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?
The EGLImage is created from the DMABuf with eglCreateImageKHR()
: https://github.com/Igalia/WPEBackend-fdo/blob/master/src/ws.cpp#L416
Weston 5.0.0
Ah, that version of Weston is known to have problems with modifiers. Could you please try with 7.0.0?
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.
That change shouldn't be needed i think. Can you try a more recent version of Weston first, please?
I believe the most recent version is 7.0.0?
It is indeed.
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).
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"
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
.
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?
You can set these env vars, COG_PLATFORM_FDO_VIEW_WIDTH=<integer>
and COG_PLATFORM_FDO_VIEW_HEIGHT=<integer>
.
right, that worked, however I'm in a loop:
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.
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.
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.
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.
Which Mesa version are you guys using?
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?
@philn 19.3.2 here, once again, ArchLinux, the latest, the greatest :-)
@WebReflection on RPi as well as @nemosupremo ?
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>
@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)
@philn that gives me a "cannot open libcogplatform-drm.so" message, failing through libWPEBackend-default.so
@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!
Sorry, I meant drm-experimental
I edited the comment after realising.
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.
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?
@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.
@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
@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!
FYI this is how my Pi4 currently boot: jellyfish demo at almost 60FPS https://youtu.be/T3BdiEe8lqA
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.
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.
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.
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.
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.
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
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.
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.
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).
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?
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.
OK, I can confirm FDO in fullscreen and full HD has no issues anymore.
@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
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?
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.
@nemosupremo I build cairo-glesv2 like this and wpewebkit like that.
Weston is 8.0.3 IIRC, ArchLinux is always on latest version available.
Hardware
Software
Command
Output
Notes
Non-fullscreen works fine. Taking a screenshot also returns correct output.