Resource: LCA14 Name: LCA14-504: Implementing a Wayland/Weston ARM based SoC Date: 07-03-2014 Speaker: Benjamin Gaignard Video: https://www.youtube.com/watch?v=IAyVMS5XJS0&list=UUIVqQKxCyQLJS6xvSmfndLA Website: http://www.linaro.org/ Linaro Connect: http://connect.linaro.org/ Slide: https://www.slideshare.net/linaroorg/lca14-lca14504-implementing-a-waylandweston-arm-based-soc

1. Fri 7 March, 11:15am, B.Gaignard
LCA14-504: Wayland / Weston

2. Wayland/Weston definitions from http://wayland.freedesktop.org/
Wayland is intended as a simpler replacement for X, easier to develop and maintain.
Wayland is a protocol for a compositor to talk to its clients as well as a C library
implementation of that protocol. The compositor can be a standalone display server
running on Linux kernel modesetting and evdev input devices, an X application, or a
wayland client itself. The clients can be traditional applications, X servers or other
display servers.
Part of the Wayland project is also the Weston reference implementation of a
Wayland compositor. Weston can run as an X client or under Linux KMS and ships
with a few demo clients. The Weston compositor is a minimal and fast compositor and
is suitable for many embedded and mobile use cases.
Wayland / Weston

3. Wayland / Weston architecture
http://wayland.freedesktop.org/architecture.html

4. It is the reference implementation of compositor for Wayland.
It include backends on DRM, X11, fbdev.
Rendering operations could be done in software with pixman or by using OpenGL.
A specific compositor has been developed for Raspberry Pi.
=> It could be the way to customize Weston for your hardware.
Since it use Mesa as OpenGL implementation proprietary EGL extensions could be
used to define a vendor-specific protocol extension that lets the client side EGL
stack communicate buffer details with the compositor in order to share buffers.
Weston

5. Client and compositor share a video buffer through Wayland protocol.
The client is responsible of drawing content in the buffer and to inform the
compositor of which part of the buffer have been updated.
The compositor in turn can take the buffer and use it as a texture when it
composites the desktop.
It is up to the client (application) to decorate the window (unlike X server).
The modifications (size, rotation, move) applied to the client window are sended to
the application to be acknowledged.
How does it work ?

6. Wayland is a protocol and so have no adherence on hardware. Just compile it !
Weston have multiple backends:
- DRM/KMS is the most common one.
- X11 but it is suboptimal because it duplicate layers and functionalities.
- framebuffer if your hardware support only that.
You could create your own backend if you have a specific composition API.
Weston provide examples of clients to test your Wayland/Weston porting.
Those examples are also very useful if you want to write your own client.
GStreamer have a video sink for Wayland.
How use it on your board ?

7. Copy from Wayland website:
“Typically, hardware enabling includes modesetting/display and EGL/GLES2. On
top of that, Wayland needs a way to share buffers efficiently between processes.
There are two sides to that, the client side and the server side.”
=> If you want to use your hardware you have to use (Mesa) EGL…
If you don’t have EGL a software fallback exist for DRM backend thanks to
pixman
This reminded us that Wayland/Weston has been design for desktop where
composition is almost done by GPU.
Those additional work is needed to run it if you have an other architecture.
Hardware Enabling for Wayland

8. OpenEmbedded provide a recipe to create a image with wayland/weston.
the command line to build it is: bitbake core-image-weston
Wayland/Weston recipes
You can found wayland, weston and weston.ini recipes in meta/recipes-graphics/wayland directory
Wayland recipe is build twice:
- one for your native environment to build wayland scanner tools
- one for your targeted environment.
You may have issues with wayland scanner if you change of wayland version, in this case clean and rebuild
wayland for your native environment:
bitbake wayland-native -f -c clean
bitbake wayland-native
How to build Wayland/Weston with OpenEmbedded

9. Wayland-core only provide buffer relying on share memory (wl_shm_buffer).
Patches to provide support of dmabuf have been submit:
http://lists.linaro.org/pipermail/linaro-mm-sig/2014-January/003597.html
There are block because 2 mains (and good) reasons:
- This protocol rely on DRM and so isn’t portable (unlike share memory)
=> we’re exploring if a generic dma-buf allocator can help here
- mmap a file descriptor is a problem for non-coherent memory architecture.
=> something need to be solve on dmabuf API
but, at least it works for ARM architecture
dmabuf and Wayland

10. More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members