User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

accelerated desktop with wayland / weston

Wed Aug 22, 2012 11:02 pm

Hi!

Has anyone else tried to get wayland work with the Raspberry Pi? If you google for "wayland raspberry pi" you'll find a video with wayland (and qt as toolkit) which works smoothly.

I got wayland-git and weston-git from AUR compiled with the Pi without problems. I had to disable all the gallium drivers in mesa-full-wayland to get it compile.

If I try to start weston with the wayland-backend I get:

failed to create display: No such file or directory
fatal: failed to create compositor

and with the drm-backend:

fatal: failed to create compositor

I think it's all about getting mesa to use the /opt/vc driver.

Can anyone point me to the right direction?

Thanks

sdjf
Posts: 1395
Joined: Fri Mar 16, 2012 5:20 am
Location: California
Contact: Website

Re: accelerated desktop with wayland / weston

Thu Aug 23, 2012 6:57 am

use strace (available in archlinuxarm repository) to possibly get more complete diagnostics.

example command, number after -s is string length of output, bigger numbers mean less is cut off:

strace -f -v -s 60 -o NAMEOFOUTPUTFILE wayland-backend &

I prefer -s 100 to catch more output, I did not check command syntax for your starting from commandline, if you need options or different command to get it running, then change "wayland-backend" to whatever is right. Are you sure it isn't supposed to be started with some kind of wrapper instead of the backend?
FORUM TIP: To view someone's posting history, sign in, click on their user name, then on "Search User's Posts." || Running ArchLinuxArm on Model 2B and 512MB Model B

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Sat Aug 25, 2012 8:43 am

Hi, sdjf!

Nice little tool! I found a few problems, but none of them was fatal except that the PKGBUILD of weston-git and cairo-gl-git are compiled against mesa librarys.

For now I got the PKGBUILD of cairo modified to build it against egl + glesv2 (instalt of egl + gl) and use the librarys in /opt/vc instead of the mesa version.

Of course the autogen.sh of weston use a different mechanism then the one of cairo, so using the some environment variables I used in cairo to point at egl and gles in /opt/vc are of no use in weston :-(

I‘ll let you now once I got weston to compile.

Btw: If anyone is interested in the PKGBUILD for cairo, I would provide it to you.

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Sun Aug 26, 2012 9:46 am

Hey, at all!

I now managed to fiddle the PKGBUILD of wayland so it does ./configure against the EGL and GLESv2 drivers in /opt/vc.

Make doesn't work at the moment:

Code: Select all

  CC       drm_backend_la-compositor-drm.lo
compositor-drm.c: In function 'drm_fb_destroy_callback':
compositor-drm.c:214:9: warning: implicit declaration of function 'gbm_bo_get_device' [-Wimplicit-function-declaration]
compositor-drm.c:214:27: warning: initialization makes pointer from integer without a cast [enabled by default]
compositor-drm.c: In function 'drm_fb_get_from_bo':
compositor-drm.c:230:9: warning: implicit declaration of function 'gbm_bo_get_user_data' [-Wimplicit-function-declaration]
compositor-drm.c:230:22: warning: initialization makes pointer from integer without a cast [enabled by default]
compositor-drm.c:248:2: warning: implicit declaration of function 'gbm_bo_get_stride' [-Wimplicit-function-declaration]
compositor-drm.c:259:2: warning: implicit declaration of function 'gbm_bo_set_user_data' [-Wimplicit-function-declaration]
compositor-drm.c: In function 'drm_output_prepare_scanout_surface':
compositor-drm.c:294:2: warning: implicit declaration of function 'gbm_bo_import' [-Wimplicit-function-declaration]
compositor-drm.c:294:29: error: 'GBM_BO_IMPORT_WL_BUFFER' undeclared (first use in this function)
compositor-drm.c:294:29: note: each undeclared identifier is reported only once for each function it appears in
compositor-drm.c:300:2: warning: implicit declaration of function 'gbm_bo_get_format' [-Wimplicit-function-declaration]
compositor-drm.c:300:31: error: 'GBM_FORMAT_XRGB8888' undeclared (first use in this function)
compositor-drm.c: In function 'drm_output_render':
compositor-drm.c:344:2: warning: implicit declaration of function 'gbm_surface_lock_front_buffer' [-Wimplicit-function-declaration]
compositor-drm.c:344:5: warning: assignment makes pointer from integer without a cast [enabled by default]
compositor-drm.c:353:3: warning: implicit declaration of function 'gbm_surface_release_buffer' [-Wimplicit-function-declaration]
compositor-drm.c: In function 'drm_output_prepare_overlay_surface':
compositor-drm.c:642:29: error: 'GBM_BO_IMPORT_WL_BUFFER' undeclared (first use in this function)
compositor-drm.c: In function 'drm_output_set_cursor':
compositor-drm.c:784:3: warning: implicit declaration of function 'gbm_bo_write' [-Wimplicit-function-declaration]
compositor-drm.c: In function 'drm_output_destroy':
compositor-drm.c:882:2: warning: implicit declaration of function 'gbm_surface_destroy' [-Wimplicit-function-declaration]
compositor-drm.c: In function 'drm_output_switch_mode':
compositor-drm.c:976:2: warning: implicit declaration of function 'gbm_surface_create' [-Wimplicit-function-declaration]
compositor-drm.c:979:6: error: 'GBM_FORMAT_XRGB8888' undeclared (first use in this function)
compositor-drm.c: In function 'init_egl':
compositor-drm.c:1129:13: error: 'GBM_FORMAT_XRGB8888' undeclared (first use in this function)
compositor-drm.c: In function 'create_output_for_connector':
compositor-drm.c:1498:11: error: 'GBM_FORMAT_XRGB8888' undeclared (first use in this function)
compositor-drm.c:1517:34: error: 'GBM_FORMAT_ARGB8888' undeclared (first use in this function)
compositor-drm.c:1518:36: error: 'GBM_BO_USE_WRITE' undeclared (first use in this function)
make[4]: *** [drm_backend_la-compositor-drm.lo] Fehler 1
make[4]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build'
make: *** [all] Fehler 2
(Fehler means error)

I installed libgbm and mesa to provide gbm.h (in which the missing functions are defined). Obviously mixing EGL from the firmware package with gbm from mesa doesn't work.

Has someone already got gbm working with the drivers of the Raspberry Pi?

Cheers,
Maribu

PS: I just found out that it's possible to attach files. Therefore I provided my PKGBUILDs. The cairo one does already compile. (Note: I had to hard reset the git source to a specific version as the newest commit breaks it. The problem may be solved by now so you can tray commenting the line out.)
Attachments
weston-raspberrypi-git-20120826-1.src.tar.gz
(1.42 KiB) Downloaded 267 times
cairo-egl-raspberrypi-git-20120824-1.src.tar.gz
(956 Bytes) Downloaded 248 times

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Mon Aug 27, 2012 8:34 am

Here is want I found out about libgbm:

GBM is a frontend to EGL used by weston (and other applications). Of course the mesa libgbm will use the mesa EGL backend.

I will have a look at: https://github.com/robclark/libgbm

If I get a libgbm frontend to use the Raspberry Pis EGL I should get weston compiled.

Cheers

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Mon Aug 27, 2012 5:50 pm

Ok, using the new libgbm (PKGBUILD attached and also updated PKGBUILD of weston) does help:

Now compiling stops with an error much later in progress ;-)

Cheers
Attachments
libgbm-raspberrypi-20120827-1.src.tar.gz
(735 Bytes) Downloaded 239 times
weston-raspberrypi-git-20120827-1.src.tar.gz
(1.42 KiB) Downloaded 254 times

pepedog
Posts: 1043
Joined: Fri Oct 07, 2011 9:55 am

Re: accelerated desktop with wayland / weston

Mon Aug 27, 2012 8:13 pm

I can see there is not much participation, but I am interested to see if you succeed. Also keeping eye through window in case there is a lion about

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Tue Aug 28, 2012 7:04 am

Hi, pepedog!

Thanks for your interest. I'm not making any progress right now. The build process crashes while making the wayland client. Actually weston is already compiled at that point (and also xwayland). I tried start weston, but after a short flicker it crashes.

Here is output of the build process:

Code: Select all

==> Beginne build()...
==> Connecting to git.freedesktop.org GIT server....
Von git://anongit.freedesktop.org/wayland/weston
 * branch            master     -> FETCH_HEAD
Already up-to-date.
==> The local files are updated.
==> GIT checkout done or server timeout
==> Starting make...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:20: installing './config.guess'
configure.ac:20: installing './config.sub'
configure.ac:10: installing './install-sh'
configure.ac:10: installing './missing'
clients/Makefile.am: installing './depcomp'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking build system type... armv6l-unknown-linux-gnueabihf
checking host system type... armv6l-unknown-linux-gnueabihf
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert armv6l-unknown-linux-gnueabihf file names to armv6l-unknown-linux-gnueabihf format... func_convert_file_noop
checking how to convert armv6l-unknown-linux-gnueabihf file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for dlopen... no
checking for dlopen in -ldl... yes
checking execinfo.h usability... yes
checking execinfo.h presence... yes
checking for execinfo.h... yes
checking for mkostemp... yes
checking for strchrnul... yes
checking for COMPOSITOR... yes
checking for XWAYLAND... yes
checking for DRM_COMPOSITOR... yes
checking for WAYLAND_COMPOSITOR... yes
checking for PIXMAN... yes
checking for PNG... yes
checking for WEBP... yes
checking for jpeg_CreateDecompress in -ljpeg... yes
checking for CAIRO... yes
checking for SIMPLE_CLIENT... yes
checking for CLIENT... yes
checking for WESTON_INFO... yes
checking for POPPLER... yes
checking for CAIRO_EGL... yes
checking for WESTON_LAUNCH... yes
checking for SYSTEMD_LOGIN... yes
checking for pam_open_session in -lpam... yes
checking for WCAP... yes
checking for rsvg-convert... no
checking for SETBACKLIGHT... yes
checking for wayland-scanner... /usr/bin/wayland-scanner
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating shared/Makefile
config.status: creating src/Makefile
config.status: creating src/xwayland/Makefile
config.status: creating clients/Makefile
config.status: creating wcap/Makefile
config.status: creating data/Makefile
config.status: creating protocol/Makefile
config.status: creating tests/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
make  all-recursive
make[1]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build'
Making all in shared
make[2]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/shared'
  CC       config-parser.lo
  CC       option-parser.lo
  CC       image-loader.lo
  CC       os-compatibility.lo
  CC       cairo-util.lo
  CCLD     libshared.la
make[2]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/shared'
Making all in src
make[2]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
  GEN      screenshooter-server-protocol.h
  GEN      screenshooter-protocol.c
  GEN      text-cursor-position-server-protocol.h
  GEN      text-cursor-position-protocol.c
  GEN      tablet-shell-protocol.c
  GEN      tablet-shell-server-protocol.h
  GEN      desktop-shell-protocol.c
  GEN      desktop-shell-server-protocol.h
  GEN      text-protocol.c
  GEN      text-server-protocol.h
  GEN      git-version.h
make  all-recursive
make[3]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
Making all in xwayland
make[4]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src/xwayland'
  GEN      xserver-protocol.c
  GEN      xserver-server-protocol.h
make  all-am
make[5]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src/xwayland'
  CC       xwayland_la-window-manager.lo
  CC       xwayland_la-selection.lo
  CC       xwayland_la-launcher.lo
  CC       xwayland_la-xserver-protocol.lo
  CC       xwayland_la-hash.lo
  CCLD     xwayland.la
make[5]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src/xwayland'
make[4]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src/xwayland'
make[4]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
  CC       desktop_shell_la-shell.lo
  CC       desktop_shell_la-desktop-shell-protocol.lo
  CCLD     desktop-shell.la
  CC       tablet_shell_la-tablet-shell.lo
  CC       tablet_shell_la-tablet-shell-protocol.lo
  CCLD     tablet-shell.la
  CC       drm_backend_la-compositor-drm.lo
  CC       drm_backend_la-tty.lo
  CC       drm_backend_la-evdev.lo
  CC       drm_backend_la-evdev-touchpad.lo
  CC       drm_backend_la-launcher-util.lo
  CC       drm_backend_la-libbacklight.lo
  CCLD     drm-backend.la
  CC       wayland_backend_la-compositor-wayland.lo
  CCLD     wayland-backend.la
  CC       weston-log.o
  CC       weston-compositor.o
  CC       weston-filter.o
  CC       weston-screenshooter.o
  CC       weston-screenshooter-protocol.o
  CC       weston-clipboard.o
  CC       weston-text-cursor-position-protocol.o
  CC       weston-zoom.o
  CC       weston-text-backend.o
  CC       weston-text-protocol.o
  CC       weston-util.o
  CC       weston-matrix.o
  CCLD     weston
  CC       weston_launch-weston-launch.o
  CCLD     weston-launch
make[4]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
make[3]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
make[2]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/src'
Making all in clients
make[2]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients'
  GEN      screenshooter-client-protocol.h
  GEN      screenshooter-protocol.c
  GEN      text-cursor-position-client-protocol.h
  GEN      text-cursor-position-protocol.c
  GEN      text-protocol.c
  GEN      text-client-protocol.h
  GEN      desktop-shell-client-protocol.h
  GEN      desktop-shell-protocol.c
  GEN      tablet-shell-client-protocol.h
  GEN      tablet-shell-protocol.c
make  all-am
make[3]: Entering directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients'
  CC       window.o
  CC       text-cursor-position-protocol.o
  AR       libtoytoolkit.a
  CC       weston-info.o
  CC       os-compatibility.o
  CCLD     weston-info
  CC       terminal.o
  CCLD     weston-terminal
libtoytoolkit.a(window.o): In function `egl_window_surface_data_destroy':
/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients/window.c:352: undefined reference to `wl_egl_window_destroy'
libtoytoolkit.a(window.o): In function `display_create_egl_window_surface':
/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients/window.c:379: undefined reference to `wl_egl_window_create'
libtoytoolkit.a(window.o): In function `window_attach_surface':
/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients/window.c:736: undefined reference to `wl_egl_window_get_attached_size'
libtoytoolkit.a(window.o): In function `window_resize_cairo_window_surface':
/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients/window.c:809: undefined reference to `wl_egl_window_resize'
collect2: error: ld returned 1 exit status
make[3]: *** [weston-terminal] Fehler 1
make[3]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build/clients'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/maribu/yaourtcache/weston-raspberrypi-git/src/weston-build'
make: *** [all] Fehler 2
==> FEHLER: Ein Fehler geschah in build().
I now asked in the wayland devel mailing list for help. Hopefully someone there can help.

Maybe I will make an qtwayland package, as this does work on the raspberry pi. But I prefer gtk :-(

A few weeks ago I managed to get directfb to work with the Raspberry Pi. At that point I didn't know that there is a gtk frontend to directfb, and because of the lack of clients I deleted it. If there isn't any progress in wayland, I'll give directfb a second try.

Cheers

krafte
Posts: 3
Joined: Sun Jul 15, 2012 3:47 pm

Re: accelerated desktop with wayland / weston

Wed Aug 29, 2012 8:24 pm

I'm also very interested in this topic, but no time at the moment to do my own investigations... So let me hear of your progress.

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Thu Aug 30, 2012 10:31 am

Hi!

I haven't made any progress since my last post. I asked in the wayland-devel mail group. But as the mail to the mail list wasn't even published by now, I don't think I could get help from them.

Personally I think you have to either built a few wrapper to get a mesa-like fronted to the Raspberry Pi graphics API - or you have to change code within weston to make it compatible to the Pi.

With OpenGL ES working fine and the libgbm I attached to one of my last post, I think it should be possible to port weston to the Pi. But you definetly have to be a better programmer than I am. All I have ever written is not much more advanced than a little "hello world program".

For now I'm giving up. But if there is someone who does have the knowlege needed and wants a beta-tester, I'll give my best to help him.

You may want to look at the new topic, I'm gonna post now.

twolife
Posts: 9
Joined: Tue Jul 31, 2012 8:03 am

Re: accelerated desktop with wayland / weston

Fri Aug 31, 2012 12:34 pm

Hi,

If i'm not misreading http://lists.freedesktop.org/archives/w ... .html#4369
, it seems that weston is not ready to run on the pi right now.

There is basically 3 backends available :
- drm/KMS/mesa
- android
- x11 (to run weston inside X11)

So, somebody will have to write a backend for the Rpi because we can't use the drm backend (the Broadcom libs don't use KMS & mesa)

Cheers

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Fri Aug 31, 2012 4:06 pm

Hi twolife!

As you now I tried the Mesa/KMS/DRI path. Mesa is only an Implementation of OpenGL. As wayland only uses OpenGL ES (because full OpenGL has dependencies to X.Org), I got this perfectly working. There is an OpenGL ES driver provided by Broadcom, and the libgbm frontend I found (PKGBUILD attached in one of my posts) seems to work.

I think the missing kernel mode setting isn't much of a problem, if my understanding of kernel mode setting is correct. The display resolution is already set at the point you start weston, also the color depth is already set.

I didn't know that it also need DRI. Looks like it is technicly possible to implement DRI via OpenVG or via OpenGL ES, but it seems to be very unlikly that anyone will do this in the near future. (Please correct me if I'm wrong.)

Has someone looked at the android backend? There is Open GL ES and OpenVG support provided by the broadcom driver, so it should be possible to get the Android Graphic Stack working on the Pi. (I think there was a video of Android 4.0 running on the Pi, so this proofs it.)

What I found out about the android graphic system is (quoted from stackoverflow.com):
There are two core pieces to Android graphics: SurfaceFlinger and Skia. SurfaceFlinger is Android's compositor, used by the window manager to create and display windows (actually called surfaces.) SurfaceFlinger is implemented on top of OpenGL ES 1.x currently and can also use other hardware acceleration techniques when available (MDP, a 2D blitter on the T-Mobile G1, or hardware overlays on the Xoom.)

Each application renders into its windows (or surfaces) using primarily Skia. Skia is Android's 2D graphics library. You can also use OpenGL ES 1.x and 2.0 to render into a surface.

Android doesn't use DirectFB or X11 or any other existing Linux solution.
So who want to work on it? (I'll do at leat give it a look.)

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Tue Sep 11, 2012 1:35 pm

You may want to look at this:
https://github.com/ciptok/RaspberryPi-BuildRoot

Some very cool guy from the wayland / weston mailings list is already working on a backend for the Raspberry Pi.

Once this is working, I'll provide PKGBUILDs.

And a quote from the e-mail he send me: "If anyone else is working on it I'm happy to talk about that." So feel free to contribute!

Regards,
Maribu

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23312
Joined: Sat Jul 30, 2011 7:41 pm

Re: accelerated desktop with wayland / weston

Tue Sep 11, 2012 2:04 pm

maribu wrote:Hi twolife!

As you now I tried the Mesa/KMS/DRI path. Mesa is only an Implementation of OpenGL. As wayland only uses OpenGL ES (because full OpenGL has dependencies to X.Org), I got this perfectly working. There is an OpenGL ES driver provided by Broadcom, and the libgbm frontend I found (PKGBUILD attached in one of my posts) seems to work.

I think the missing kernel mode setting isn't much of a problem, if my understanding of kernel mode setting is correct. The display resolution is already set at the point you start weston, also the color depth is already set.

I didn't know that it also need DRI. Looks like it is technicly possible to implement DRI via OpenVG or via OpenGL ES, but it seems to be very unlikly that anyone will do this in the near future. (Please correct me if I'm wrong.)

Has someone looked at the android backend? There is Open GL ES and OpenVG support provided by the broadcom driver, so it should be possible to get the Android Graphic Stack working on the Pi. (I think there was a video of Android 4.0 running on the Pi, so this proofs it.)

What I found out about the android graphic system is (quoted from stackoverflow.com):
There are two core pieces to Android graphics: SurfaceFlinger and Skia. SurfaceFlinger is Android's compositor, used by the window manager to create and display windows (actually called surfaces.) SurfaceFlinger is implemented on top of OpenGL ES 1.x currently and can also use other hardware acceleration techniques when available (MDP, a 2D blitter on the T-Mobile G1, or hardware overlays on the Xoom.)

Each application renders into its windows (or surfaces) using primarily Skia. Skia is Android's 2D graphics library. You can also use OpenGL ES 1.x and 2.0 to render into a surface.

Android doesn't use DirectFB or X11 or any other existing Linux solution.
So who want to work on it? (I'll do at leat give it a look.)
Just saw this post - worth a comment. There is already a Broadcom implementation of Surfaceflinger for the Android port. Not sure when that will be made publicly available. The Android demo from a while back used this for GPU acceleration of the GUI.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

dextrus
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
Contact: Website

Re: accelerated desktop with wayland / weston

Sun Nov 11, 2012 12:17 pm

I see there has been some movement on this front!

http://wayland.freedesktop.org/raspberrypi.html

I did try and follow the instructions, but I must be doing something wrong with the packages because the final autogen stage fails (complains it can't find a number of packages). I'm sure someone more familiar with building would have a better chance than me.

It also complained about not having doxygen. I could have ignored that but decided to install it. Boy what a mistake that was! It took hours!

/Dextrus
Have more FUN with your Pi. Visit www.pi-fun.com

Mogwai
Posts: 21
Joined: Thu Jul 26, 2012 4:08 pm
Location: Montreal
Contact: Website

Re: accelerated desktop with wayland / weston

Mon Nov 12, 2012 11:29 pm

dextrus wrote: I did try and follow the instructions, but I must be doing something wrong with the packages because the final autogen stage fails (complains it can't find a number of packages). I'm sure someone more familiar with building would have a better chance than me.
/Dextrus
I built a working Wayland / Weston following those same instructions.
Wrote about it here: http://www.intestinate.com/pilfs/#wayland
Hope it might be of some help.

dextrus
Posts: 119
Joined: Tue Jan 24, 2012 10:10 pm
Location: Eastleigh, Hampshire
Contact: Website

Re: accelerated desktop with wayland / weston

Wed Nov 14, 2012 11:39 pm

Thanks for that! Very detailed instructions!

/Dextrus
Have more FUN with your Pi. Visit www.pi-fun.com

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Fri Nov 16, 2012 7:14 pm

Hi, there!

Thanks for your help. I used your howto to make a PKGBUILD. I attached all PKGBUILD needed which are not in the AUR.

You should follow this order when generating the packages:

cairo-egl (see the attached PKGBUILD)
libxkbcommon (see AUR)
wayland-git (see AUR)
libgbm-raspberrypi (see the attached PKGBUILD)
weston-raspberrypi-git (see attached PKGBUILD)

Make sure you haven't installed waylang-egl.pc (this breaks the weston build).

With the resulting weston package I can start weston and see a mouse cursor (which does move when I move my mouse) and a panel with a clock. I haven't figured out yet how to launch some applications. But I'll work on that.

Hint: You can close weston with ctrl+alt+backspace

Has anyone got xwayland already working? I mostly use gtk+-2.0 applications. And as far as I know there is only (early and buggy) wayland support for gtk+-3.0. So I have to work with X for now.

By the way: Does someone know if its permitted to upload PKGBUILDs to the aur which are only targeted on the arm platform? Provided you have yaourt you could install weston on the Pi with basically one command in this case.

Regards,
Maribu

PS: If some PKGBUILD is missing or you have an idea how to improve my PKGBUILD let my know.
Attachments
weston-raspberrypi-git-20121116-1.src.tar.gz
(1.53 KiB) Downloaded 211 times
libgbm-raspberrypi.src.tar.gz
(735 Bytes) Downloaded 210 times
cairo-egl-raspberrypi-git.src.tar.gz
(956 Bytes) Downloaded 223 times

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Fri Nov 16, 2012 8:05 pm

Ok, I found out that I can configure weston and the panel it draws via ~/.config/weston.ini

Code: Select all

[shell]
type=desktop-shell.so
background-image=/usr/share/backgrounds/gnome/Aqua.jpg
background-color=0xff002244
panel-color=0x90ff0000
locking=true
animation=zoom
#binding-modifier=ctrl
#num-workspaces=6

#type=tablet-shell.so
#lockscreen-icon=/usr/share/icons/gnome/256x256/actions/lock.png
#lockscreen=/usr/share/backgrounds/gnome/Garden.jpg
#homescreen=/usr/share/backgrounds/gnome/Blinds.jpg
#animation=fade

#[launcher]
#icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png
#path=/usr/bin/gnome-terminal

[launcher]
icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png
path=/usr/bin/weston-terminal

#[launcher]
#icon=/usr/share/icons/hicolor/24x24/apps/google-chrome.png
#path=/usr/bin/google-chrome

[launcher]
icon=/usr/share/icons/gnome/24x24/apps/arts.png
path=./clients/flower

[screensaver]
# Uncomment path to disable screensaver
path=/usr/libexec/weston-screensaver
duration=600

#[output]
#name=LVDS1
#mode=1680x1050
#transform=90

#[output]
#name=VGA1
#mode=173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
#transform=flipped

#[output]
#name=X1
#mode=1024x768
#transform=flipped-270
This is the way it looks at the moment. I can launch a terminal with that, but just when the window shows up weston freezes. I still can kill weston via kill -9 over ssh, but I don't get properly back to tty: I can see my tty again, but it does not react to keyboard input. I have to reboot the Pi via ssh.

Another thing: There should be an application called "weston-launch" (and there is the source code for it) but it does not get compiled. Is this the correct behaviour for the Raspberry Pi port of weston?

Regards,
Maribu

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Fri Nov 16, 2012 9:13 pm

Ok, at the howto it is suggested to either edit /boot/config.txt and add "dispmanx_offline=1" or start weston with "--max-planes=0". I did none of them and this seemed to crash weston-terminal. I now launched weston with "--max-planes=0" (and didn't edit config.txt) and weston-termnal works.

It really looks promising.

Regards,
Maribu

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Sun Nov 18, 2012 11:44 am

Ok, I've started to make packages for wayland and the first thing I've looked at is xwayland. Sadly, the package does not compile right now:

Code: Select all

xwayland.c: In function 'xwl_input_delayed_init':
xwayland.c:87:5: warning: implicit declaration of function 'wl_display_get_global' [-Wimplicit-function-declaration]
xwayland.c:87:5: warning: nested extern declaration of 'wl_display_get_global' [-Wnested-externs]
xwayland.c:89:9: warning: implicit declaration of function 'wl_display_bind' [-Wimplicit-function-declaration]
xwayland.c:89:9: warning: nested extern declaration of 'wl_display_bind' [-Wnested-externs]
xwayland.c:89:33: warning: assignment makes pointer from integer without a cast [enabled by default]
xwayland.c: In function 'global_handler':
xwayland.c:110:25: warning: assignment makes pointer from integer without a cast [enabled by default]
xwayland.c:114:25: warning: assignment makes pointer from integer without a cast [enabled by default]
xwayland.c: In function 'wakeup_handler':
xwayland.c:135:2: warning: implicit declaration of function 'wl_display_iterate' [-Wimplicit-function-declaration]
xwayland.c:135:2: warning: nested extern declaration of 'wl_display_iterate' [-Wnested-externs]
xwayland.c:135:42: error: 'WL_DISPLAY_READABLE' undeclared (first use in this function)
xwayland.c:135:42: note: each undeclared identifier is reported only once for each function it appears in
xwayland.c: In function 'block_handler':
xwayland.c:146:31: error: 'WL_DISPLAY_WRITABLE' undeclared (first use in this function)
xwayland.c: In function 'xwl_screen_pre_init':
xwayland.c:231:5: error: 'noScreenSaverExtension' undeclared (first use in this function)
xwayland.c:234:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'Atom' [-Wformat]
xwayland.c:252:6: warning: implicit declaration of function 'wl_display_add_global_listener' [-Wimplicit-function-declaration]
xwayland.c:252:6: warning: nested extern declaration of 'wl_display_add_global_listener' [-Wnested-externs]
xwayland.c:251:33: warning: assignment makes pointer from integer without a cast [enabled by default]
xwayland.c:258:2: error: too many arguments to function 'wl_display_get_fd'
In file included from xwayland.c:35:0:
/usr/include/wayland-client.h:144:5: note: declared here
xwayland.c: In function 'xwl_screen_close':
xwayland.c:297:2: warning: implicit declaration of function 'wl_display_remove_global_listener' [-Wimplicit-function-declaration]
xwayland.c:297:2: warning: nested extern declaration of 'wl_display_remove_global_listener' [-Wnested-externs]
make[5]: *** [libxwayland_la-xwayland.lo] Fehler 1
make[5]: Leaving directory `/home/maribu/wayland/xwayland-xorg/src/xserver/hw/xfree86/xwayland'
make[4]: *** [all] Fehler 2
make[4]: Leaving directory `/home/maribu/wayland/xwayland-xorg/src/xserver/hw/xfree86/xwayland'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/maribu/wayland/xwayland-xorg/src/xserver/hw/xfree86'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/maribu/wayland/xwayland-xorg/src/xserver/hw/xfree86'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/maribu/wayland/xwayland-xorg/src/xserver/hw'
make: *** [all-recursive] Fehler 1
Someone already asked for this here http://permalink.gmane.org/gmane.comp.f ... devel/5666. According to this post it's because xwayland does require weston / wayland in version 0.85 and has not been ported to current 1.0 version. So we have to wait a bit for xwayland beeing ported.

Nest thing I'll look at is sdl on wayland. I also thought about having a look at chromium (or google chrome) which does has wayland support. But I decided to better keep using a smaller browser either via xwayland or gtk+-3.0.

Which packages would you use on wayland? Does someone need help making a PKGBUILD?

Regards,
maribu

User avatar
maribu
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm

Re: accelerated desktop with wayland / weston

Mon Nov 19, 2012 12:40 pm

Here are my precompiled packages:

https://www.dropbox.com/sh/5l5fq0xoafgv7i2/pxI0IXchF7

I haven't tried out sdl over wayland right now. At the moment I'm working on gtk3 and currently I have to modify pango-unstable to get compiled against the correct GLES and EGL implementation (and not against mesa).

Regards,
Maribu

dmp
Posts: 6
Joined: Sun Mar 24, 2013 6:57 pm

Re: accelerated desktop with wayland / weston

Sun Mar 24, 2013 7:08 pm

Mogwai wrote: I built a working Wayland / Weston following those same instructions.
Wrote about it here: http://www.intestinate.com/pilfs/#wayland
Hope it might be of some help.
Thank you for your a big job.
I am beginner in linux and LFS too.
Can you write more detailed instruction about building xorg for the wayland? Is it really need or wayland can work without xorg usage?
Thank you very much.

Mogwai
Posts: 21
Joined: Thu Jul 26, 2012 4:08 pm
Location: Montreal
Contact: Website

Re: accelerated desktop with wayland / weston

Sun Mar 24, 2013 8:58 pm

dmp wrote:Thank you for your a big job.
I am beginner in linux and LFS too.
Can you write more detailed instruction about building xorg for the wayland? Is it really need or wayland can work without xorg usage?
Thank you very much.
You will need to build xorg as wayland/weston depends on some xorg libraries etc.
But it's really not that complicated to build.
Just follow http://www.linuxfromscratch.org/blfs/vi ... xorg7.html and you'll be fine.
Site updates are coming soon, I'll try to elaborate a bit more on wayland.

dmp
Posts: 6
Joined: Sun Mar 24, 2013 6:57 pm

Re: accelerated desktop with wayland / weston

Mon Mar 25, 2013 6:49 am

Mogwai wrote:You will need to build xorg as wayland/weston depends on some xorg libraries etc.
But it's really not that complicated to build.
Just follow http://www.linuxfromscratch.org/blfs/vi ... xorg7.html and you'll be fine.
Site updates are coming soon, I'll try to elaborate a bit more on wayland.
thank you for quick answer.
I plan to write an application as clean client of wayland and I don't want to use tails xorg, if possible.
Is it possible? If answer is NO - what are libraries of xorg needed to run the wayland?
May be it is 3...7 concrete libraries?
I want make system with as minimal as possible needed libraries and I dont want install full xorg.

Return to “Arch”