Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can I run weston with userland? #966

Open
timemaster5 opened this issue Dec 4, 2021 · 5 comments
Open

Can I run weston with userland? #966

timemaster5 opened this issue Dec 4, 2021 · 5 comments

Comments

@timemaster5
Copy link

timemaster5 commented Dec 4, 2021

Description

This might not be an issue, but I am just confused about patches found in this layer, especially ones in the userland recipe, which add support for Wayland and EGL, and so on.

This closed issue also doesn't help :)
#243

My main goal is to have an accelerated h264 video playback on a rotated screen on Rpi 3 CM3+.
I've tried everything I could and spent already weeks literally to get this job done without success.

By everything, I mean combinations of:

  • kernel version 4.19.x, 5.4, and 5.10 (multiple revisions of each)
  • firmware from 2019 releases up to the latest bullseye
  • GStreamer versions 1.16 to 1.18
  • userland/vc4graphics
  • multiple mesa versions (if applicable)

My conclusion is that the vc4 driver in the kernel is still not mature and bug-free enough to get me there.
Not even in the latest 5.10.x and bullseye firmware. The errors I see in the dmesg are described here:
raspberrypi/linux#3791 (comment)

After getting back to the roots with userland, I started having luck, where I could play a video nicely, only with some minor GStreamer error after each loop. I am pretty confident I will resolve this one somehow later on if this is the right way at all. However, this way is more limiting to my other requirements. For example, without Weston running on the vc4 mesa driver, I cannot rotate the screen. I could use display_hdmi_rotate in config.txt though, but this one strangely works only for 720p; on 1080p, the picture is garbled (I have also tried multiple firmware revisions without success). Shall I open a bug for this somewhere?

EDIT: I have opened the issue for 90deg rotation on 1080p screen. I suspect u-boot doing this.
#968

So I started digging into a Weston running on the RPI backend, but I found out that this one was dropped long ago.
Newer mind, I found multiple patches, which seems like Weston should run nicely on EGL provided by userland, but that is not my case, unfortunately :(

I would be glad if I could discuss this topic personally with someone on discord or email. However, I think I have to miss some piece of info because my requirements are nothing special, and in my opinion, many people would want the same from their Pies.

Steps to reproduce the issue:

  1. MACHINE="raspberrypi-cm3"
  2. DISABLE_VC4GRAPHICS=1
  3. IMAGE_INSTALL_append = " weston"
  4. set dtoverlay to vc4-kms-v3d to enable /dev/dri/card0

Describe the results you received:

[14:13:39.349] Command line: weston --tty 1
[14:13:39.349] OS: Linux, 5.4.83-v7, #1 SMP Wed Jan 20 09:59:41 UTC 2021, armv7l
[14:13:39.349] Using config file '/etc/xdg/weston/weston.ini'
[14:13:39.350] Output repaint window is 7 ms maximum.
[14:13:39.350] Loading module '/usr/lib/libweston-8/drm-backend.so'
[14:13:39.355] initializing drm backend
[14:13:39.356] logind: failed to get session seat
[14:13:39.356] logind: cannot setup systemd-logind helper (-61), using legacy fallback
[14:13:39.360] using /dev/dri/card0
[14:13:39.360] DRM: supports universal planes
[14:13:39.360] DRM: supports atomic modesetting
[14:13:39.360] DRM: supports picture aspect ratio
[14:13:39.360] Loading module '/usr/lib/libweston-8/gl-renderer.so'
MESA-LOADER: failed to open vc4 (search paths /usr/lib/dri)
failed to load driver: vc4
MESA-LOADER: failed to open kms_swrast (search paths /usr/lib/dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast (search paths /usr/lib/dri)
failed to load swrast driver
[14:13:39.366] failed to initialize egl
[14:13:39.393] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.

Describe the results you expected:
I would like to have Weston running with userland drivers.

Additional details (revisions used, host distro, etc.):
Raspberry Pi Compute Module 3+
yocto poky
mainly dunfell, but I tried recipes from meta-raspberrypi master too

@agherzan
Copy link
Owner

agherzan commented Jan 4, 2022

VC4 should be mature enough to use now. I have been working on top of it for a good while now.

@timemaster5
Copy link
Author

Hm, not for me :( do you use some hardware-accelerated video decoding in your projects? The support is better on Rpi4, but on the Rpi3 or ComputeModule 3, there is still a bug in the kernel which prevents me from using the VC4 unfortunately :(
I am trying to push it forward to make it more visible in the linux-raspberrypi GitH, but so far there wasn't a big movement.

@timemaster5
Copy link
Author

Anyway, this question was mainly to prevent confusion. I couldn't find much of the documentation or some better info online. I just wasn't sure whether it was supposed to work or not (Weston with userland drivers). The list of patches seems like it should, but at the same time I think it is now deprecated as Weston has dropped support of an RPI backend. So maybe those Weston patches for userland are now deprecated too. If they were meant for the RPI backend.

@agherzan
Copy link
Owner

I see. That clarifies it now. What is the situation on Raspbian? Could we try to have a comparison with the reference RPi distro?

@timemaster5
Copy link
Author

Not good. I have tried RaspberryOS because I wanted to know if they know better or not, of course :) but I found out that HW decoding is disabled by default in the default installation. I tried the integrated browser, and an included video player. Both were using software decoding on my Rpi3b+. Some issues have been opened in the raspberry kernel tree GitHub for a long time. I am trying to keep the discussion running, do some tests and so on, but there isn't much will on fixing this, which I am surprised about. The issue which concentrates most info is here raspberrypi/linux#3791. There are links to some other related bugs, not only in my latest post. From time to time, someone rewrites the v4l implementation of the hw codecs almost from scratch or something around it, but from my perspective, the bug is still the same :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants