What's new in Weston 13?

Last Tuesday, Weston 13.0 has been released. The release contains several new features that have been developed and mainlined for our embedded systems' use cases. In this blog post, we would like to explain the new features relevant for us — multi-backend, OpenGL renderer for the PipeWire and VNC backends and overlapping outputs — and outline why those are important for embedded usecases.

New Features

With the Multi-Backend feature, it is now possible to have an additional remote-control- or streaming feature for a system where Weston controls the output on a locally connected display. Up to now, Weston was restricted by the fact that only one backend could be active at the same time, and thus only outputs of one type (i.e. DRM or VNC) were available. Now with the multi backend, this restriction is gone and Weston can now create outputs of different types, so for example we can now operate a DRM, VNC and PipeWire output in one system in parallel. For many embedded systems with networking, a remote-control operation is a welcome feature.

Embedded hardware is still performance constrained, so hardware accelerated rendering stays important. Up to now, the VNC and PipeWire backend could only be used with the Pixman software renderer. Starting with Weston 13, these backends can also make use of the OpenGL accelerated renderer. In Weston, a renderer can be shared for all backends, so this does also allow to continue using the GL renderer for the DRM backend when a PipeWire or VNC output is added. Therefore, drawing operations can be performed on the GPU instead of the CPU and hardware ressources can be utilized in a more efficient way.

The support of overlapping outputs has interesting effects for our usual use cases. First of all, hardware planes can now be also used for windows being displayed on multiple outputs. Hardware planes partially make it possible to combine multiple windows on the display output path, thus leading to more ressource availability on the GPU. Secondly, it is now possible to display the same desktop content on multiple outputs. Before this change, damage tracking constraints made it necessary to separate outputs completely, which in turn lead to workarounds to show a window both on DRM and VNC.

Upcoming Work

Even with those features now being in mainline, we won't run out of work soon. The following features to improve performance and configuability of Weston for embedded systems are now planned.

There is already a merge request for DMABUF-support for the PipeWire backend. With this feature, Weston can hand over GL rendered frames directly to PipeWire and, without a copy, further on to hardware accelerated JPEG- or H.264 encoders. This makes it possible to get rid of unnecessary copies of large buffers, resulting in better performance for streaming and recording.

A similar optimization would be desirable for the VNC backend; this will need more work in Neat VNC.

Another issue is that currently the config options for multiple outputs are quite constrained. We are missing a feature to position outputs on the desktop and configure their size, both by configuration (similar to the clone mode) and programatically, with a plugin. The programmatic part could be combined with a hypothetic window management infrastructure. It is also desired to create and remove the VNC and PipeWire outputs on runtime.

Nevertheless, Weston continues to prove being a great Wayland compositor for embedded systems. It makes sense to update your own systems to Wayland 13.


Further Readings

Weston, VNC Server

In March last year I gave a talk about our work on the Wayland compositor Weston at the Embedded Recipes conference, and demonstrated using multiple backends simultaneously. A single Weston instance provided content to a range of different outputs, e.g.: