As instructed on http://wayland.freedesktop.org/raspberrypi.html , weston RPi backend requires pkg-config files for raspberry userland libraries; I guess manual AC_CHECK_LIB stuff would have been too suboptimal as a fallback with a /opt/vc prefix or something. These are told to be found on http://cgit.collabora.com/git/user/pq/android-pc-files.git/tree/pkgconfig?h=raspberrypi They should be placed in $(libdir)/pkgconfig - that way thanks to the $prefix used in those, stuff can actually find the libraries out of /opt/vc without hacks (provided pkgconfig is in /usr prefix as $(libdir) is) Without them, weston build will use stubs for these headers, which is documented in the stub file itself as "This file CANNOT be used to build a working rpi-backend, it is intended only for build-testing, when the proper headers are not available.", so any hope for actual more "out of the box" success stories, we need these pkgconfig files and some related tweaks to weston I'll follow-up on separately once I get things to work. As such, this is untested by me as of yet, but hopefully that's a matter of hours or a day to report back on - while this bug ensures it doesn't get forgotten after I manually put the files there. If I forget to follow-up (if it's needed), just poke on IRC :) Just as I mis-hit the Submit Bug button, I noticed there was also bug 494076, but I'm pretty sure the conclusion in regards to them provided by mesa is incorrect, as the ones referenced here would point them at the correct /opt/vc path. But maybe they are still somehow workable; either way, as the reporter there seems interested in the topic, CCing him too.
With these pkg-config files dropped to /usr/lib/pkgconfig I got the rpi-backend.so built for weston with USE flags "X editor launch rpi suid" with the rest of IUSE disabled (-drm, -resize-optimization, -egl, -gles2 and -opengl explicitly on purpose for the time being). Without the pkg-config files, it didn't install the .so; not sure, maybe it builds it for build testing, don't have a log now... :( Getting it successfully running is a whole different matter though. But that would be something for weston package, not raspberrypi-userland that this bug is about.
I've only been playing with RPi for a little over 2 months now, and I filed that bug you referenced before I had a good grasp how everything is supposed to fit together for RPi. Mesa does provide EGL, GLES related pkg, but not for hw acceleration. I'm currently building bleeding edge stuff that hasn't been mainlined yet, so what I'm doing may not apply, but it may at some point in the future. I'm building userland with this patchset applied: https://github.com/raspberrypi/userland/pull/110 It provides hw acceleration needed for wayland / weston RPi backend. I cobbled the relevant pkgconifg files together by hand. I do not currently have mesa installed. I'm using libgbm in its place: https://github.com/robclark/libgbm I've modified some ebuilds, and others I build by hand and add a line in package.provided. To make things even more complicated, I'm also trying (unsuccessfully) to get this to work using systemd for init. Things that I've been able to build with the patched userland: -cairo (untested due to weston not working) -vlc (tested) -gst-omx (tested) -omxplayer (tested) -wayland (untested, passes all "make check" tests) -weston (untested, seems to have issues with logind from systemd that I haven't been able to sort out) -qt-5.2 (not tested, built manually from monolithic package. Too many changes needed in qt5 overlay to build it from portage) Things not building correctly: -gst-plugins-bad (problems with incompatible EGL code) -qtwayland (the build system is totally screwed up) Also something you might find of interest: https://github.com/cnvogelg/glues
I figured I should add, that I'm doing all this in hopes of eventually getting the hawaii desktop working (with hw accleration) for RPi.
My target is xwayland and gst-omx for starters; then can see about trying to go native. So without those patches I get hardware overlays used for fancier and smooth Super key behaviour in Weston, but actually no acceleration of stuff? I wonder if then in xserver didn't have anything, and this would be a huge improvement; or it's a regression until wayland support patched into rpi-userland? As for weston-1.4.0 not working, I found this mailing list thread: https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg12491.html I have basic Wayland and Weston working now via downgrading weston to 1.3.91, while having it use the pkg-config files to build weston rpi backend properly, which this bug is about. Maybe there is a small chance of issues with 1.4.0 because it starts to depend on the rpi-userland patches you linked? But probably not then if 1.4.0 broke for you too, and you seem to be patching that stuff from Tomeu in already. Either way, I think the pkg-config files should get added then :) Perhaps for collaborating the general work on getting it going on Gentoo as best as possible, we could move that conversation to IRC on #gentoo-embedded or the like?
To get media-libs/cogl[-opengl,gles2] to successfully build, I had to add glesv2 to egl.pc's Requires line. But it also points out that the DT_NEEDED entries of raspberrypi-userland installed libEGL.so and libGLESv2.so seem to be out of whack. glxx_client_state_free is just the last out of many symbols libEGL.so references, but libGLESv2.so provides, while libEGL.so doesn't have a DT_NEEDED on libGLESv2.so
Most of my RPi related hacks in regards to wayland, gstreamer and more are now in my overlay - http://git.overlays.gentoo.org/gitweb/?p=dev/leio.git
*** Bug 494076 has been marked as a duplicate of this bug. ***
fixed in raspberrypi-userland-0_pre20160305-r1.ebuild commit 06c415c57f1452d3376499ff82128d9b7013f64a Author: Miroslav Šulc <fordfrog@gentoo.org> Date: Thu Mar 10 15:04:43 2016 +0100 media-libs/raspberrypi-userland: bug fixes and improvements fixed bug #539504: support for GLESv1 fixed bugs #499768 and #529424: added pkgconfig files and set environment path to these files fixed location of udev rules file fixed bug #499768: added support for wayland from leio.git overlay Package-Manager: portage-2.2.27
I actually have grown various reservations about these pkg-config files by now as long as upstream doesn't get involved here. But maybe they did and I missed the mails from the upstream bug. Thanks for all the other inclusions, I'll try to take a closer look and sync my overlay up sometime this year :D
Oh, and the reservations are in terms of what happens when both mesa and raspberrypi-userland installs these files - they are named the same, conflicts if installs to where other stuff will see it automatically (/usr/lib*/pkgconfig instead of opt), which gets picked together with some differences in EGL header typedefs compared to mesa, etc etc. This conflict aspect is especially important now that you can actually get all this from mesa VC4 as well now as an alternative open source driver.
(In reply to Mart Raudsepp from comment #10) > Oh, and the reservations are in terms of what happens when both mesa and > raspberrypi-userland installs these files - they are named the same, > conflicts if installs to where other stuff will see it automatically > (/usr/lib*/pkgconfig instead of opt), which gets picked together with some > differences in EGL header typedefs compared to mesa, etc etc. > This conflict aspect is especially important now that you can actually get > all this from mesa VC4 as well now as an alternative open source driver. yes, i am aware of the fact that the files conflict with mesa. that's why i put them in /opt/vc. maybe blocking mesa[egl,gles1,gles2] would be a solution. in that case we could install those files where they belong. i was also wondering why these libs are put in /opt/vc but did not want to touch it unless there is some consensus about it. up to that, the paths are now hardlinked in other ebuilds to /opt/vc so it would require touching other ebuilds aswell. not mentioning the fact that we also have raspberrypi-userland-bin which is now imo obsolete and makes the things even more complicated.
blocking mesa in any form would be a no-no imho. I suppose it can be fine like this then for now, so we'd mess with PKG_CONFIG_PATH for things that need these. But then there might be a problem when something needs bcm_host and egl, but egl doesn't have to be raspberrypi-userland one. E.g it needs bcm_host, but can handle also egl from mesa just fine (either software implementation or VC4 driver based). Then to see bcm_host we need to mess with PKG_CONFIG_PATH but then it also sees rpi-userland stuff for egl and co that exist in mesa too. Of course the VC4 mesa stuff complicates things further - like why build the 3D stuff in rpi-userland at all when you want VC4, yet you might want the OpenMAX, bcm_host and other stuff. Anyways, upstream bug is https://github.com/raspberrypi/userland/issues/245 I think it's fine for now and we can revisit this once looking into VC4 properly and when someone is working on rebasing other stuff on top of this (gst-omx, etc). I am unlikely to get around to plugging in my rpi stuff before April/May myself, but if anyone is interested in getting more stuff to work out of the box, I can always help via IRC chats meanwhile.
i did not mean blocking whole mesa as that would not work i guess, i mean blocking just those use flags that i mentioned. in fact that is how i had it on my rpi. if you look at /usr/portage/virtual/opengl/opengl-7.0-r1.ebuild, there are two implementations(mesa and opengl-apple) that block each other. also eselect opengl is the way to select opengl implementation so you can probably have several implementations and just switch among them. that affects which implementation is linked to the executables. idk whether it was raspberrypi-omxplayer or kodi but one of them needs raspberrypi-userland because mesa does not implement some stuff. anyway switching to raspberrypi-userland opengl implementation by eselect links the stuff correctly. it's still not 100% clear to me yet but at least it works :-)
The wayland-wsys.patch added in the fix for this bug is empty. The original patch is probably too large for ${FILESDIR}, though.
