LCA14: LCA14-504: Implementing a Wayland/Weston ARM based SoC


Published on

Resource: LCA14
Name: LCA14-504: Implementing a Wayland/Weston ARM based SoC
Date: 07-03-2014
Speaker: Benjamin Gaignard
Linaro Connect:

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

LCA14: LCA14-504: Implementing a Wayland/Weston ARM based SoC

  1. 1. Fri 7 March, 11:15am, B.Gaignard LCA14-504: Wayland / Weston
  2. 2. Wayland/Weston definitions from 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. 3. Wayland / Weston architecture
  4. 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. 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. 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. 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. 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. 9. Wayland-core only provide buffer relying on share memory (wl_shm_buffer). Patches to provide support of dmabuf have been submit: 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. 10. More about Linaro Connect: More about Linaro: More about Linaro engineering: Linaro members: