Wayland #110
Wayland #110
Conversation
|
FWIW, I have built the raspberry pi userland Tomeu's pull request and then the latest Weston/Wayland from their repository on my Raspberry Pi and conducted some tests. Everthing seems to be working fine. Looking forward for this to be available in Raspbian. If there is anything I can do please ask. Thanks!. |
|
Currenlty building userland (from the buildme script) both as a cross compile or natively is much more complicated. Currently most users will do: which will generate complaints from people just wanting to rebuild raspicam. |
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: wl_dispmanx_server_buffer should probably be defined in a private header that can be included from EGL and vc_* instead of in vc_vchi_dispmanx.h
|
Have made the new code disabled by default and updated the README with instructions to enable it. |
|
Thanks, will take a look. |
|
I'm putting this here since it hasn't been pulled yet... I very well may doing something incorrectly, as this is the first time I've tried to mess with this DispmanX accelerated version of weston. |
|
@ReubenM It appears dispmanx functions are being called without vc_vchi_dispmanx_init being called. |
|
I patched this down onto my buildroot based system that has weston, the various weston samples, hello_dispmax, and the hello_pi GL samples running. For some reason, running hello_wayland from the weston terminal crashes with "failed to get wl_dispmanx" in init_process_wayland(). my guess is that process->wl_dispamax is null and that it has something to do with registry_handle_global where that gets set. Here's my weston startup log: |
|
@joshzana Looks like your Weston doesn't have wl_dispmanx support. |
|
I assumed that this line: |
|
For what it's worth, I still haven't been able to get it to work either. I rebuild latest wayland / weston from git now and then to see if anything changed, but still doesn't seem to work. Wayland tests all pass. The first 2 tests for Weston pass, but the rest fail. Mine is a bootstrapped gentoo build using systemd init. Built on a binfmt chroot image that is then duplicated to the SD card. |
|
For the record, I ended up getting it to work a few months ago under Raspbian, and I'm still running Wayland/Weston with @tomeuv 's fork. I'm using the very latest Weston and Wayland from their respective official git repos, using the Raspberry Pi build guide but with the flags I also added Finally, I had to add There was also a specific sequence to which these projects had to be built and installed. I think it was Wayland first, then @tomeuv 's fork of the Broadcom Userland drivers, then Weston. I could be wrong on that, let me know if that's the case. Whew. |
|
One last bit, and this was recently updated in the Raspberry Pi build guide last month, is that I can only run Weston from the root user, or as user |
|
Yes, I've done all that. I've set up a weston group, created pc files for the bits and pieces that don't have them. Build flags and environment variables. I haven't added -lrt to LDFLAGS, but I assume the build would fail if it couldn't find the lib to link to. The main difference is that I'm building from this official code base with the patch applied, rather than from the tomeuv fork. Perhaps changes since the fork are causing runtime problems without causing compile problems. I've also been wondering if perhaps there is some issue with read/write access to various system files/devices/sockets that would have been dealt with in Raspbian that wouldn't be present by default in a Gentoo base that I'm not yet aware of. |
|
@ReubenM Could it be that you are building the userland.git with assertions enabled? IIRC we had similar mysterious problems no-one else had before, and the fix was to just disable the assertions. Are the asserts still your problem? I think Raspbian does have some permission configurations that might be missing from other distros, but nothing you have said points the problem being in that direction. |
|
@ReubenM Also, are you talking about 'make check' in the Weston tree? If so, this has quite a lot of known issues upstream, and is very, er, picky, especially relating to input. I'd still assume it's a permissions issue from your Gentoo+systemd setup, though it's hard to see without any further detail than 'something fails'. |
|
@ppaalanen Where is it that assertions are disabled? I saw no such option available from cmake. (At least no such option was exposed when setting flags/options in interactive mode) @fooishbar Sorry, yes I was speaking in reference to the 'make check' tests. I can get more details on the test failures in a few days if that would help. I had just assumed the QC tests probably weren't updated to work with the RPi environment yet. |
|
@tomeuv - OK I got my wayland building with --enable-egl and that fixed the hello_weston so it displays under weston compositor. I do see an odd artifact in that it appears to draw a single frame and then go blank, and come back if I move the mouse. |
|
@ppaalanen Ah, I realize that I had not set the build type to release, so the DNDEBUG flag was not being set. I'll see if that fixes it when my RPi boxes get back. (There are on a truck somewhere coming back from a show I used them on) |
|
First, my root partition is formated in F2FS and I realized that the mainline raspberry pi kernel 3.10.y is not able to mount F2FS with user_caps functionality enabled. So I bumped my kernel version to the 3.12.y branch to get caps working. I then rebuilt userland with assertions disabled and updated wayland / weston to latest git (1.4+) Here's the terminal output now from weston: [18:33:45.534] OS: Linux, 3.12.7+, #1 PREEMPT Sun Jan 26 20:34:19 CST 2014, armv6l This may have to do with my lack of understanding of the new logind session devices. Can anyone provide any insight into what I might need to check to make sure weston can work in conjunction with logind? |
|
@ReubenM Are you sure you are running weston from a local login, and not via remote login? Also not from an X terminal, but a bare VT session? I'm not familiar with the logind integration, but I think those are required. |
|
X is not installed, and I was attempting to launch it logged into VT1. (So naturally I'm wondering what is behind the "session not running on a VT" message.) |
|
I may have found what is causing the problem: From this email: https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg11056.html "(4) Reading VTNR from systemd is now supported (requires systemd-207, I'm using systemd-208. Maybe that is this issue. |
|
Hi, I've applied the patch, that seems to work flawlessly, but I get an error message when using qt5 with wayland-egl backend, the application reports "can't find eglconfig returning null config". Just wondering if it's normal. (Maybe I forgot something) |
|
My fault, some lines of the patches were skipped... |
|
just FYI, I was able to get weston-1.4 to load with this version of userland after patching weston with the recent commit in weston trunk to fix the input output device init order. (very fragile though) |
|
@tomeuv Hi, I'm trying to build your wayland branch but get this error interface/vmcs_host/vc_vchi_dispmanx.h:72:66: fatal error: interface/vmcs_host/wayland-dispmanx-server-protocol.h: No such file or directory I can't see the file in there. Could you perhaps let me know where this is? Thanks! |
|
@ajlennon Seems to me that there was some problem generating that file. It should be generated by wayland-scanner and you should have gotten an earlier error about it. |
|
Thanks Tom. I'm trying to create a recipe to build this within Yocto so there may well be. I'll take a look around wayland-scanner then. Thanks again. |
|
Is this initiative got abandoned (or I'm missing it's reincarnation somewhere)? |
|
There are proper kernel and mesa drivers being developed that will render http://dri.freedesktop.org/wiki/VC4/
|
|
Right. The decision was to not work further on the old drivers, and wait for the new drivers (Mesa + KMS) to be developed. This is underway, as it has been for some time, and when they are complete, we should have native Wayland support. There is no currently-published ETA for this happening however. |
…: raspberrypi/userland#110 Patches have been rewrite to let the code building with the latest version of userland.
…: raspberrypi/userland#110 Patches have been rewrite to let the code building with the latest version of userland.
This commit add the Pull request agherzan#110 to userland recipe raspberrypi/userland#110 Patches habe been rewrited to let the code build with the latest revision of userland.
This commit add the Pull request agherzan#110 to userland recipe raspberrypi/userland#110 Patches have been rewrited to let the code build with the latest revision of userland.
|
Hi @tomeuv there is a problem I encounter after I apply tomeuv@c22c00f . The in git/interface/khronos/CMakeLists.txt gets to run before the header is This leads me to the same error @ajlennon had pointed above. Any hints on how to fix this? |
|
Ping? |
|
This PR needs to be refreshed isnt it ? For the record I noticed couple of work in process : agherzan/meta-raspberrypi@2a84a6a Seems this be backported to dizzy , is there someone maintaining a such branch ? |
This commit add the Pull request #110 to userland recipe raspberrypi/userland#110 Patches have been rewrited to let the code build with the latest revision of userland. Change-Id: I82e85ff7a4c6fb1c6c80986f74042fbd1d562809 Signed-off-by: Philippe Coval <philippe.coval@osg.samsung.com>
|
@rzr We have no plans to update this branch. The open-source Mesa 'vc4' driver for Raspberry Pi is a much better option to use, though you do need quite a new kernel. The driver this patches still has a number of issues when running under Wayland, which are not easily fixable. |
|
If you use Weston's rpi-backend, please see this and spread the word: |
|
Yea DRM support will be far better |
|
@rzr Right, and that is very much our long-term plan. However, while KMS support is not enabled by default, we want to get an idea of how many people this would affect. |
|
@tomeuv is this PR still relevant? If it is, the conflicts should be resolved... |
|
@Ruffio No, the vc4 Mesa/KMS drivers resolve this for us. |
|
Then please close the PR |
|
@fooishbar as this has been resolved, please close/reject this PR... |
|
@Ruffio I don't have permission to do so. |
|
@popcornmix can you close/reject this PR? |
|
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant. |
While waiting, I have fixed a couple of bugs regarding resource deallocation, making it more correct and perhaps more robust. Support has been already merged into Weston and people are waiting for this to be available in Raspbian to test. Thanks!