Wayland #92
Wayland #92
Conversation
|
With this PR the building of userland is much more onerous. (other schemes to make building simpler would also be fine). |
|
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? |
|
@JamesH65 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. |
|
@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. |
|
Is a header file missing from PR? |
|
@popcornmix : this "missing" file is supposed to be generated by wayland-scanner, but there seems to be something wrong with the makefile. workaround: |
|
@twolife I note now that anything that links with libEGL will no longer link: presumably all makefiles that use libEGL will need a library added (libwayland-server?) to link? |
|
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. |
|
@tomeuv : the problem i (we?) have with the files generated by wayland-scanner isn't related to crosscompiling, a native build still fails. |
|
@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? |
|
@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" |
|
@twolife That's indeed a bug, I'm cooking a fix for it. |
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.
* 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
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>
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>
These patches provide support for the Wayland platform, but please note the TODO items in the main commit.