mali450-userland: Remove libwayland-egl install

[alimon]

Since Wayland 1.15.0 provides it's own version of libwayland-egl,

http://git.openembedded.org/openembedded-core/commit/?id=6e5952fcfc13ff4b63c9376bd41a1dbba957f425

As I reviewed there is no way to disable libwayland-egl in wayland build, this will fix oe-rpb-master build futher testing is needed in HiKey machine.

Signed-off-by: Aníbal Limón anibal.limon@linaro.org

[alimon]

@ndechesne @mrchapp @fboudra @koenkooi Please review to fix rpb master build.

[fboudra]

@andrey-konovalov

[andrey-konovalov]

I gave this change a try on HiKey board: weston failed to start. Not sure if it was due to this particular change (using libwayland-egl.so from wayland vs libMali.so), or the Mali blob being not compatible with weston 5.0, or something else.

The rpb-weston-image build completed OK for hikey.

On the target weston failed to start (below is the output of journalctl -u weston@linaro): -----8<----- -- Logs begin at Fri 2018-10-26 07:52:22 UTC, end at Fri 2018-10-26 16:00:28 UTC. -- Oct 26 16:00:06 hikey systemd[1]: Starting Weston Wayland Compositor (on tty7)... Oct 26 16:00:07 hikey systemd[1]: Started Weston Wayland Compositor (on tty7). Oct 26 16:00:07 hikey systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mweston@linaro.service: Main process exited, code=exited, status=1/FAILURE[[0m Oct 26 16:00:07 hikey systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mweston@linaro.service: Failed with result 'exit-code'.[[0m -----8<-----

Under /usr/lib I see: -----8<----- root@hikey:~# ls -l /usr/lib/libwayland-egl.so lrwxrwxrwx 1 root root 23 Oct 26 15:35 /usr/lib/libwayland-egl.so.1 -> libwayland-egl.so.1.0.0 -rwxr-xr-x 1 root root 5848 Oct 26 08:43 /usr/lib/libwayland-egl.so.1.0.0 -----8<----- If I change /usr/lib/libwayland-egl.so to be symlinks to libMali.so, weston fails to start as well.

/usr/lib/libwayland-egl.so.1.0.0 has (objdump -TC output): -----8<----- 000000000000758 g DF .text 000000000000001c Base wl_egl_window_get_attached_size 0000000000000728 g DF .text 0000000000000030 Base wl_egl_window_destroy 00000000000006a0 g DF .text 0000000000000028 Base wl_egl_window_resize 00000000000006c8 g DF .text 0000000000000060 Base wl_egl_window_create -----8<----- usr/lib/libMali.so has some more wl_eglwindow* functions: -----8<----- 00000000000c0820 g DF .text 000000000000002c Base wl_egl_window_insert_surface 00000000000c0938 g DF .text 0000000000000030 Base wl_egl_window_get_attached_size 00000000000c0708 g DF .text 00000000000000b4 Base wl_egl_window_create 00000000000c07d0 g DF .text 0000000000000050 Base wl_egl_window_unref 00000000000c08cc g DF .text 000000000000006c Base wl_egl_window_destroy 00000000000c06e0 g DF .text 0000000000000028 Base wl_egl_window_resize 00000000000c084c g DF .text 0000000000000080 Base wl_egl_window_remove_surface 00000000000c07bc g DF .text 0000000000000014 Base wl_egl_window_ref -----8<-----

[andrey-konovalov]

Well... I managed to get the /run/user/1000/weston.log, and this is what was in there: -----8<----- Date: 2018-10-26 UTC [16:33:25.235] weston 5.0.0 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: unknown (not built from git or tarball) [16:33:25.235] Command line: /usr/bin/weston --log=/run/user/1000/weston.log [16:33:25.235] OS: Linux, 4.9.0+, #1 SMP Fri Oct 26 08:22:03 UTC 2018, aarch64 [16:33:25.236] Using config file '/etc/xdg/weston/weston.ini' [16:33:25.237] Output repaint window is 7 ms maximum. [16:33:25.237] Loading module '/usr/lib/libweston-5/drm-backend.so' [16:33:25.249] Failed to load module: /usr/lib/libweston-5/drm-backend.so: undefined symbol: gbm_bo_get_offset [16:33:25.249] fatal: failed to create compositor backend -----8<-----

libMali.so (the current r7p0-01rel0 version) doesn't implement gbm_bo_get_offset(). gbm_bo_get_offset() is a relatively recent addition to mesa (less than 2 years old, introduced in mesa 17.1.0): https://cgit.freedesktop.org/mesa/mesa/commit/src/gbm?id=2ee34bd5dcf30f202c9f37e3d986640f71b8a210

And weston has started using the new API about 1 year ago: https://gitlab.freedesktop.org/wayland/weston/commit/244244d11b5a9168656dd613029a0feb4879aff7

mali450-userland doesn't provide any headers, and lets mesa to install its ones. In oe-core, master mesa version is currently 18.1.9. mesa 18.1.9 does have gbm_bo_get_offset(), and weston_5.0.0's do_configure relies on that. Looking at the above weston commit, it seems like it could be enough to make mali450-userland to report gbm version < 17.1 to fix this issue.

[petegriffin]

@alimon Can you re-work your fix based on Andreys suggestion? As currently this change breaks HiKey board.

[alimon]

@alimon Can you re-work your fix based on Andreys suggestion? As currently this change breaks HiKey board.

@petegriffin Hi, I don't have a HiKey to test the changes, this change was an intent to fix oe-rpb master build.

[petegriffin]

@alimon it is certainly an improvement that the build completes. But it would be even better if it worked at run time as well.

Maybe @ndechesne can get you a HiKey board shipped. It sounds like it would be useful if your task is to keep master builds working.

[ndechesne]

well, i would rather have someone in charge of Hikey to avoid failures in the first place.. looking at Andrey's comment we are not even sure that this is a trival thing.. it could be a blob issue..

I totally understand that keeping oe-rpb-master to build can be quite a bit of work. alternatively we can remove hikey from default builds as well.

[petegriffin]

well, i would rather have someone in charge of Hikey to avoid failures in the first place

That would definitely be good. Currently it seems like it is done on a best effort basis by various people/teams. Maybe you could persuade the HiSi landing team to help support the board.

looking at Andrey's comment we are not even sure that this is a trivial thing.. it could be a blob issue..

If gbm is reported as >= 17.1 it will enable the #ifdef HAVE_GBM_MODIFIERS code path and use the new API (and cause a blob linking issue). If not the behavior should be the same as before. So it seems hopeful that Andreys suggestion will work. It is obviously a good thing that the build now completes, but it would be even better if it worked at run time. In case it is a blob issue I have requested this be put on the agenda for the next Linaro Mali call.

I totally understand that keeping oe-rpb-master to build can be quite a bit of work. alternatively we can remove hikey from default builds as well.

IMO if you're going to fix the master builds, it is important to invest the effort to fix things properly. We can't keep "fixing" RPB by removing the SoC/board or package that is failing. Otherwise RPB will just become the "Qcom OE build".

[petegriffin]

I'm going to try https://github.com/petegriffin/meta-96boards/commit/94e835fe0e26d328fa0851580cf047a5559b9c8a to see if it fixes the run time issue.

[petegriffin]

@alimon @andrey-konovalov @ndechesne With Anibal patch on this pull and also https://github.com/96boards/meta-96boards/pull/281/commits applied Weston desktop comes up OK

[fboudra]

LGTM and per @petegriffin comment, merging this change.