Wayland #92

Closed
wants to merge 6 commits into
from

5 participants

@tomeuv

These patches provide support for the Wayland platform, but please note the TODO items in the main commit.

@popcornmix

With this PR the building of userland is much more onerous.
Many users will just want to rebuild, say, the camera apps, and it seems unreasonable for them to go through the procedure of building wayland/weston.
Can you make the effect of this PR optional - e.g. with "WANT_WAYLAND=1".

(other schemes to make building simpler would also be fine).

@JamesH65

Just out of interest....Is that a one off build, once done, not rebuilt unless changed? How long does the build actually take (PC and Pi?) when including Wayland etc?

@popcornmix

@JamesH65
It's a one off.
See http://wayland.freedesktop.org/raspberrypi.html for what needs to be done.
I think the amount of code is small enough that it can be built on Pi fairly quickly (minutes rather than hours), but it comes from a number of repos, so it's a bit involved.

A top level "buildme" script that clones and builds (possibly even launched from userland build script), or a deb package that can be installed to get the libs needed (pre-installed in a future raspbian image) would be other solutions.

But just making this PR optional for now would make it easier to accept.

@fooishbar

@popcornmix To build EGL, you only need the core Wayland library, which doesn't require any of xkbcommon/Weston/etc. It's also available in the raspberrypi.collabora.com repo.

@popcornmix

Is a header file missing from PR?

/home/pi/userland/interface/vmcs_host/vc_vchi_dispmanx.h:71:64: fatal error: interface/khronos/wayland-dispmanx-server-protocol.h: No such file or directory
@twolife

@popcornmix : this "missing" file is supposed to be generated by wayland-scanner, but there seems to be something wrong with the makefile.

workaround:

make -f interface/khronos/CMakeFiles/khrn_static.dir/build.make interface/khronos/CMakeFiles/khrn_static.dir/depend
@popcornmix

@twolife
That did fix my problem. I've got it build natively on Pi (not with cross compile yet).

I note now that anything that links with libEGL will no longer link:
/opt/bcm-rootfs/opt/vc/lib/libEGL.so: undefined reference to `wl_resource_set_implementation'

presumably all makefiles that use libEGL will need a library added (libwayland-server?) to link?

@tomeuv

Sure, this dependency can be made optional if the maintainer makes it a condition for acceptance. Though it may be a separate issue to let people build a subset of the sources (maybe split the repository?)

The Wayland libraries on which these patches depend should be already packaged in any major distro. I expect the latest stable versions to be available on Raspbian soon (though normally first code gets accepted upstream, then downstream updates its packages).

But for cross-building, maybe we should find a way for cross-compile builds to pick up dependencies from a RPi chroot, otherwise upstream.git gets very limited in what it can do.

About the trouble with the files generated by wayland-scanner, it's a fundamental problem with cross-building, as you have to use the tools compiled for the host arch, unless you use something like scratchbox that emulates the target arch.

For easiness of hacking, my suggestion would be to split the base libraries into their own repo(s), and let everybody use the packaged binaries for their distro unless they hack on the libraries themselves. Then have one or more repositories with the sample apps. They are so small that probably doesn't make much sense to cross-compile them. If done properly, no git history would be lost when splitting the repositories.

@twolife

@tomeuv : the problem i (we?) have with the files generated by wayland-scanner isn't related to crosscompiling, a native build still fails.

@tomeuv

@twolife Well, there is a problem with cross-compiling and running binaries that don't belong to the toolchain, but this doesn't mean that you cannot find any other problems :)

Can you give more details on what problem are you having with native builds?

@twolife

@tomeuv here is the log : http://paste.debian.net/52671/

as you can see it's not a too big problem because i'm able to generate the files "by hand", but it's clearly "not cool"

@tomeuv

@twolife That's indeed a bug, I'm cooking a fix for it.

Dom Cobley and others added some commits Jul 9, 2013
Dom Cobley Allow applications to set next resource handle
This patch adds provisions in userland to
let apps callers set the next rendereing dispmanx resource.
It's useful for implementing, say, a buffer carousel.
f02d927
@tomeuv tomeuv wayland: Add support for the Wayland winsys
* Adds EGL_WL_bind_wayland_display extension
* Adds wayland-egl library
* Adds wl_dispmanx_buffer protocol extension

TODO: Check that platform_get_dimensions() returning swapchain_count == 1 is correct

TODO: Remove the requirement of passing a valid DispmanX element handle to
the SwapBuffers and CreateSurface RPC calls. This will remove the need to open
a DispmanX display from the clients.

TODO: The server-side wl_dispmanx_buffer should probably be defined in a
private header that can be included from EGL and vc_* instead of in
vc_vchi_dispmanx.h
1771f9f
@tomeuv tomeuv wayland: Add Wayland example 98602a6
@tomeuv tomeuv wayland: Move dispmanx.xml up so it can be better shared by libraries a79ebec
@tomeuv tomeuv wayland: Properly release buffers when a surface is destroyed 6c48058
@tomeuv tomeuv wayland: Add command switches to hello_wayland to force resource release e97e3ea
@tomeuv tomeuv closed this Oct 25, 2013
@tpetazzoni tpetazzoni pushed a commit to buildroot/buildroot that referenced this pull request Nov 1, 2013
@yann-morin-1998 yann-morin-1998 package/rpi-userland: add patch to remove faulty assert()
While porting wayland/weston to run on the RPi, I always tripped on
this assert.

Thinking there was an issue with weston, I poked the weston guys on
IRC about the issue. 'daniels' on irc.freenode.net/#wayland suggested
removing the assert altogether, as that's what they had pushed
upstream in their wayland pull-request:
    raspberrypi/userland#92

Turns out they forgot to include this in their pull-request, but that
they were using a patched rpi-userland without that assert.

And indeed, without that assert, weston runs on the RPi. :-)

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
a863451
@philenotfound philenotfound pushed a commit to philenotfound/buildroot-cr15wi that referenced this pull request Sep 23, 2014
@yann-morin-1998 yann-morin-1998 package/rpi-userland: add patch to remove faulty assert()
While porting wayland/weston to run on the RPi, I always tripped on
this assert.

Thinking there was an issue with weston, I poked the weston guys on
IRC about the issue. 'daniels' on irc.freenode.net/#wayland suggested
removing the assert altogether, as that's what they had pushed
upstream in their wayland pull-request:
    raspberrypi/userland#92

Turns out they forgot to include this in their pull-request, but that
they were using a patched rpi-userland without that assert.

And indeed, without that assert, weston runs on the RPi. :-)

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ddebce0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment