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 resources 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 resource 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 configurability 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 programmatically, 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.