horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Thu Apr 12, 2018 7:22 am

I am sorry, creating libclutter symlinks to directory manually is not a very wise idea, I did it, but after ldconfig it again restores links to previous links to old installed libraries from respository (strangely recompiled libgtk still works)
Anyway, after repairing my system with autoconf, it seems, like I am able to rewrite old installed libraries with newly rebuilt libraries (with --libdir/usr/lib/arm-linux-gnueabihf ) and make install installs the built ones to /lib/arm-linux-gnueabihf.
But now again this problem:

/home/pi/NetBeansProjects/dist/Debug/GNU-Linux/multistreamviewer: symbol lookup error: /usr/local/lib/libclutter-1.0.so.0: undefined symbol: cogl_wayland_renderer_set_event_dispatch_enabled

my /usr starts to be very messy with all these attempts, seems like I have to do it again from scratch.
If you think that is is more reasonable to use --prefix instead of --libdir, please, let me know, I did not no any other way, how to change the installation directory from /usr/lib/arm-linux-gnueabihflib to /usr/lib/arm-linux-gnueabihf
Omitting lib from ${exec_prefix}/lib to ${exec_prefix}/ in ./configure file led to an error while make install, but that could have bee cause by my problems which could have been thenafter resolved by command autoconf.
Which way is more reasonable --prefix and omitting lib or setting --libdir or is it pretty much the same?

thank you
Best regards,
Ivo

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Thu Apr 12, 2018 10:22 am

fruitoftheloom wrote:
Fri Oct 20, 2017 9:17 am
BillStephenson wrote:
Thu Oct 19, 2017 9:53 pm
Just curious (as I know very little of the tech specifics), will this have any impact on further work on this here?:

The future of Wayland, and sway's role in it

It was stated above that Wayland / Weston has been abandoned at this present time as a replacement for Xorg in Raspbian Operating System.

Wayland is around 10 years old and it will likely be several more years before Debian make the switch ;)
The switch to Wayland could take some time, but Wayland in Debian has support for GTK and clutter therefore applications based on both work, this is a big difference from Raspbian, anyway Fedora seems to use it as default.
I just curious whether it will help with performance issues on Raspberry, epecially for applications with graphical backend.

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Fri Apr 13, 2018 4:16 pm

Ok I finally made it. Just --libdir and autoconf did most of the magic.
GTK application on Wayland works, CLUTTER also works hopefully with COGL, no problem running Weston after start.
Video rendering is a bit slow, but could be caused by Weston, GTK, clutter and gstreamer combination, working application is a good start.

Thank you all for help

User avatar
Alexander Brown
Posts: 97
Joined: Thu Jan 23, 2014 2:36 pm

Re: Wayland on stretch

Fri Apr 13, 2018 6:06 pm

Ok I finally made it. Just --libdir and autoconf did most of the magic.
GTK application on Wayland works, CLUTTER also works hopefully with COGL, no problem running Weston after start.
Video rendering is a bit slow, but could be caused by Weston, GTK, clutter and gstreamer combination, working application is a good start.

Thank you all for help
Congrats

If only Raspbian didn't disable Wayland support in the first place...
I am

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Wayland on stretch

Fri Apr 13, 2018 10:12 pm

If you are using a pi 2/3 then you could just use pure debian. It might be easier than recompiling gtk/mesa/etc

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Sat Apr 14, 2018 2:30 pm

Thank you for suggestion, like you said that is reasonably when having ARM v7, but my application is supposed to work on arm v6 (Pi Zero), we use RPI3 only for compilation and testing and also there is no official image yet, I believe it could be very good in some ways (64 bit support) but I stick with Raspbian so far.
Anyway, the slow video rendering drives me crazy, it could be caused by clutter as clutter seems to be running on top of COGL because of this:
When running my application X11, I experienced huge increase in speed when running video rendering in X11 (in a window) using clutter but switching the video driver from default one to VC4 KMS (I guess it is OpenGL not OpenGL|ES2), that means Gallium on top of VC4 driver in X11. I don't know much about the layers behind but default repository COGL library with X11 support only could be build with GLES2 and OpenGL (GL) support and it could detect drivers internally and utilize the driver whichever is available (that was probably done in my case with X11, when KMS driver was present, it started to use OpenGL instead of GLES2 and the video rendering speed increased dramatically), unfortunately I built COGL with GLES2 support and without GL support (I guess this is the KMS openGL driver) moreover in COGL ./configure there is also some gstreamer support disabled by default.
These are all the reasons I suspect the OpenGL driver to be responsible for the speed increase. I'll enable GLES2 (or maybe disable GLES2 to make sure it is not using GLES2 but GL), GL and gstreamer and give it a try.
Weston (Wayland) is definitely running on Gallium VC4, EGL, at least according to log file so I hope there is no need to touch both.

What I don't fully understand is Eric Anholt statement:
VC4 at the hardware level is a GLES 2.0 renderer. However, along with GLES 2.0, the Mesa driver also exposes OpenGL 2.1, which is mostly correct but with a few caveats.

I don't know if this statement could mean that using OpenGL could speed up video rendering compared to GLES 2.0 if both are GLES2 renderers on hardware level.

Please, if anyone is reading this conversation, I would like to encourage all to comment any wrong statement I have mentioned, I don't find myself any expert in this field and I want to make clear I understand the underlying issues properly in order to optimize video speed in Wayland.
By the way, could anyone also explain me why Wayland support in Raspbian was postponed for indefinite, I read everywhere how better Wayland should be compared to X11, there are multiple videos on Youtube showing benefits of Wayland/Weston fast window rendering compared to poor X11 performance.
It is just because of the fact the whole distribution would require a lot of work to suit and tune all applications to Wayland backend or is Raspbian waiting for for Debian to make Wayland default?

User avatar
Alexander Brown
Posts: 97
Joined: Thu Jan 23, 2014 2:36 pm

Re: Wayland on stretch

Sat Apr 14, 2018 4:59 pm

I believe lack of documentation for the VideoCore was a factor

It's a shame because back in the Wheezy days I managed to run Maynard and experienced the benefits first hand, sure Maynard was incredibly incomplete and Weston (especially the XWayland plugin) was rather buggy back then but the performance over X11 on the Pi1 was insane

These days I use Wayland on everything but Raspbian
I am

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Wayland on stretch

Sat Apr 14, 2018 6:12 pm

horai wrote:
Sat Apr 14, 2018 2:30 pm
Thank you for suggestion, like you said that is reasonably when having ARM v7, but my application is supposed to work on arm v6 (Pi Zero), we use RPI3 only for compilation and testing and also there is no official image yet, I believe it could be very good in some ways (64 bit support) but I stick with Raspbian so far.
Anyway, the slow video rendering drives me crazy, it could be caused by clutter as clutter seems to be running on top of COGL because of this:
When running my application X11, I experienced huge increase in speed when running video rendering in X11 (in a window) using clutter but switching the video driver from default one to VC4 KMS (I guess it is OpenGL not OpenGL|ES2), that means Gallium on top of VC4 driver in X11. I don't know much about the layers behind but default repository COGL library with X11 support only could be build with GLES2 and OpenGL (GL) support and it could detect drivers internally and utilize the driver whichever is available (that was probably done in my case with X11, when KMS driver was present, it started to use OpenGL instead of GLES2 and the video rendering speed increased dramatically), unfortunately I built COGL with GLES2 support and without GL support (I guess this is the KMS openGL driver) moreover in COGL ./configure there is also some gstreamer support disabled by default.
These are all the reasons I suspect the OpenGL driver to be responsible for the speed increase. I'll enable GLES2 (or maybe disable GLES2 to make sure it is not using GLES2 but GL), GL and gstreamer and give it a try.
Weston (Wayland) is definitely running on Gallium VC4, EGL, at least according to log file so I hope there is no need to touch both.

What I don't fully understand is Eric Anholt statement:
VC4 at the hardware level is a GLES 2.0 renderer. However, along with GLES 2.0, the Mesa driver also exposes OpenGL 2.1, which is mostly correct but with a few caveats.

I don't know if this statement could mean that using OpenGL could speed up video rendering compared to GLES 2.0 if both are GLES2 renderers on hardware level.

Please, if anyone is reading this conversation, I would like to encourage all to comment any wrong statement I have mentioned, I don't find myself any expert in this field and I want to make clear I understand the underlying issues properly in order to optimize video speed in Wayland.
By the way, could anyone also explain me why Wayland support in Raspbian was postponed for indefinite, I read everywhere how better Wayland should be compared to X11, there are multiple videos on Youtube showing benefits of Wayland/Weston fast window rendering compared to poor X11 performance.
It is just because of the fact the whole distribution would require a lot of work to suit and tune all applications to Wayland backend or is Raspbian waiting for for Debian to make Wayland default?
I missed the bit about the pi zero. I've got a pi 1 and have given up using it for desktop stuff. I had rather assumed everybody else had too on the pi 0/1. It really is painful to use.

You can install debian armhf and arm64 via the official debian installer images/ISO's. You just need to add the pi bootloader files. But like you say, it won't work on the zero.

Vc4 hasn't got accelerated video decode yet as far as I am aware, so performance is always going to be poor on a zero. I find all the OpenGL/gles/etc stuff very confusing too.

I'm guessing Maynard was retired because it was a pain to maintain and vc4 showed such promise. The problem is that Wayland has been slow to be adopted generally. Most apps to be converted to it are the really heavy resource (memory/CPU) use ones, so they are unsuited to the pi. Whenever I've used Wayland via mutter (gnome window manager) on my laptop the performance has been rubbish. I'm sceptical about it ever being suitable for the pi.

I still think compiz can't be beaten as a window manager. It's been a while since I tried it on a pi, but it was working alright except for a few crashes. The problem with it is it requires gpu memory and since this is shared on the pi, it can limit further what is an already limited resource. Compiz 0.8 uses OpenGL and can be used with fkms, so you can use omxplayer with it. I've not tried it with the desktop wrappers for omxplayer. I don't know if that helps you at all?

Edit: compiz debs I made a while back viewtopic.php?t=192010

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Sat Apr 14, 2018 7:52 pm

Ok, I probably did not explain it properly, I have GUI application on top of X11 based on GTK, clutter and gstreamer, it is supposed to render real time video stream in a window and it has few GUI buttons to control the stream, thanks to all these technologies it runs on Pi Zero on top of X11 very fine, but we want to increase the speed to have even smoother video and Wayland was one option.
Without VC4, running video in X11 windows (with my knowledge and experience) was impossible except some attempts resulting more or less in a slideshow no matter which gstreamer sink I used. The well known OMX player was not an option as we needed GUI, so we found a solution with clutter, GTK on top of X11 with VC4.
Buying a cheap tablet with Android would probably be the easiest way, but my mind keeps telling me not to do it, maybe that is the point where craziness starts :)

User avatar
Alexander Brown
Posts: 97
Joined: Thu Jan 23, 2014 2:36 pm

Re: Wayland on stretch

Sat Apr 14, 2018 8:39 pm

In theory that should work brilliantly

Unfortunately to really see benefits you would have to use the rpi-backend for Weston but that was scrapped as it only ever supported Pi1 on Wheezy

That said Pi0 is close enough to Pi1 you may be able to get Wheezy to run but you would have things like Gtk 3.4 instead of 3.22 so debatable if you would gain much
I am

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Wayland on stretch

Sat Apr 14, 2018 8:49 pm

You might still see a bit of a performance increase with compiz. It improves firefox.

Have you had a look at how the omxplayer wrappers work? e.g. https://github.com/Meticulus/tomxplayer Until the video decode is improved with vc4 (viewtopic.php?f=63&t=210945 ), then I think that is the only way you are going to really improve performance.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Wayland on stretch

Sat Apr 14, 2018 9:15 pm

Reading Eric Anholts blog, things don't seem to be far away with video decode on vc4. https://anholt.github.io/twivc4/2018/02/12/twiv/

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Sun Apr 15, 2018 5:31 pm

Actually, if we are talking about decoding H264, that is done by the OMX gstreamer plugin utilizing the GPU core having hardware accelerated H264 video deconding/encoding. GPU's OpenGL hadware acceleration is used to enhance the speed of video rendering using clutter via KMS VC4 driver.
That is how I understand how things work in this case, maybe I am wrong.

horai
Posts: 43
Joined: Fri Apr 21, 2017 2:45 pm

Re: Wayland on stretch

Sun Apr 15, 2018 6:04 pm

Alexander Brown wrote:
Sat Apr 14, 2018 8:39 pm
In theory that should work brilliantly

Unfortunately to really see benefits you would have to use the rpi-backend for Weston but that was scrapped as it only ever supported Pi1 on Wheezy

That said Pi0 is close enough to Pi1 you may be able to get Wheezy to run but you would have things like Gtk 3.4 instead of 3.22 so debatable if you would gain much
I guess you are very much right with the rpi-backend, but there is also a statement about the rpi-backend that it was removed intentionally because a drm layer was improved, so I guess Collabora would point out some major differences, wouldn't they?
https://www.collabora.com/news-and-blog ... -raspbian/
This article is not that old anyway and weston is being prepared as a package even for Stretch.

Actually, I don't know much about the RPI backend and how it is related, according to this picture:
http://3.bp.blogspot.com/-yp99PzEORDI/T ... d-arch.png

Or maybe this is a bit more understandable for me (refer to Wayland section):
http://oopsmonk.github.io/blog/2017/05/ ... phic-stack

It might be the EGL Wayland platform, right?

User avatar
Alexander Brown
Posts: 97
Joined: Thu Jan 23, 2014 2:36 pm

Re: Wayland on stretch

Sun Apr 15, 2018 8:44 pm

As far as I'm aware rpi-backend was an alternative to all almost all DRM stuff and was specific to the VC rather than generic

I'm not particularly knowledgeable in that low level area of the Linux graphics stack I'm afraid
I am

Return to “Raspbian”