Earlier this week, Weston 16.0 was released. It brought many improvements, expanding and refining features introduced in Weston 15.

Highlights

HDR and color management

Since the previous release, we have implemented more color management and HDR support features. This includes better performance, more test coverage, and support for many new use cases. Now it's finally possible to turn HDR mode on. HDR support remains experimental due to the lack of tone mapping, and we need more experience with picture quality.

We have added interoperability between parametric and ICC profiles. This is essential for fully supporting the color-management protocol and enabling a wide range of color-aware applications. Displays that use ICC profiles can now work with HDR clients, and clients using ICC profiles can be displayed on HDR displays.

For now only colorimetric rendering intents are fully supported in transformations that involve parametric image descriptions. We are working to add a tone and color gamut mapping for perceptual and saturation rendering intents.

We changed Weston's default sRGB profile from ICC to parametric, making surfaces from color-unaware clients use the parametric image description. ICC profiles can still be set on surfaces through the color-management protocol and configured as the output profile in weston.ini.

HDR displays are automatically set up to use a parametric image description. With this change, enabling HDR displays and displaying HDR content should be simple by configuring just colorimetry-mode and eotf-mode for the output.

In Weston's GL-renderer, we have added support for in-shader blending. This is useful for saving bandwidth and memory when color-management is enabled. Also, it allows us to support color-management on more devices.

Another useful addition is support for the newest kernel Mode Setting (KMS) uAPI to offload per-plane color transformations. Weston is now able to offload pre-blend color transformations using this. A new KMS uAPI to offload post-blend color transformations is currently a work-in-progress, and we are already experimenting with that in Weston.

Perfetto debug annotations

This Weston release builds on top of the previously added Perfetto instrumentation, further expanding the debug information you can get out of Weston. You can now see all the GL-renderer optimizations, buffer information, and input events on the ingress side (from libinput), and equality on the egress side, when input events are being delivered to Wayland clients.

Example of Perfetto right after opening the trace file, riddled with debug annotations:

Example of Perfetto tracking a pointer motion event:

Example of Perfetto showing GL debug annotations:

Further work is now in progress to improve debugging on the native DRM backend, and expand additional debug annotations at call sites where it makes sense to have them.

Lots of new features and optimizations for the DRM backend

DRM properties support

This release adds support for two new DRM properties BACKGROUND_COLOR, a CRTC property, and COLOR_FORMAT, a DRM connector property.

While Weston gained the ability to offload a solid background color with Weston 15, we couldn't do the same with arbitrary colors. This new CRTC background color property rectifies that, allowing us to now offload a custom solid background color using KMS.

The other DRM property gives users the possibility to choose between saving bandwidth or preserving fidelity. For instance, for better bandwidth usage, one would set up the same color-format for a particular connector as the content, while for preserving fidelity you'd stick to non-sampled RGB. By default Weston would set this property to AUTO, letting the driver pick whatever it decides as being default. Depending on the hardware, possible other options are YUV 4:2:2, YUV 4:4:4, YUV 4:2:0, and of course, RGB.

With this new release the DRM backend can now set underscan properties, which gives users the possibility to tweak out Weston's output edges in order to compensate for display overscan - a case where the frame buffer content is spilled off the edges of the display, a handy tweak which can be used on TVs which are affected by this issue.

As previously stated on the topic about color management, Weston has gained the ability to offload pre-blend color transformations to KMS. To be able to do that, the DRM backend had to gain support for using KMS color pipeline, work which was used to help develop and validate the kernel uAPI proposal.

DRM backend optimizations

The DRM backend has gained an optimization feature which allows it to reuse the previous state whenever there weren't any scene-graph modifications. This should improve CPU usage, as Weston may now skip an internal decision tree that was run every repaint cycle, drastically improving efficiency on lower-end processors and allowing us to make harder decisions during plane selection.

Another useful optimization is that now we can have KMS states without primary planes. This is convenient when, due to various reasons, the primary KMS plane can't be used, but overlays are a good match for the content being offloaded to KMS.

Various changes, improvements, and overall fixes

Improved performance when debugging

In this release we've taken some considerable steps to improve Weston's performance when using debug scopes. This would be useful for potential lower-spec CPUs, as flushing out considerable amounts of data might incur some performance penalty on platforms using those CPUs. Underneath, this avoids needless memory allocation, stores various pieces of information without needing to regenerate them on each output repaint, or routes data through less expensive libc printing functions.

Alpha modifier protocol support

This Weston release added support for the alpha modifier protocol, allowing clients to set an alpha factor on a surface. This allows them to produce transparency effects, such as dimming and fade-in/fade-out animations, by simply changing the alpha factor instead of re-rendering their content. Without this protocol, clients may have to re-render and commit their buffers for each animation frame, increasing GPU usage.

Improved writeback screenshots

Screenshots taken with the writeback connector with a different framebuffer size than that of the attached CRTC would now be permitted, allowing the writeback connector to perform a scale operation if hardware is capable of that. This further required a kernel documentation update to describe that possibility.

More DRM pixel formats support

Weston is now aware of more DRM formats enabling AFBC compression for YUV-type buffers found on Hantro codec engines and Mali GPUs.

Renderer fixes and updates

The experimental Vulkan renderer saw fixes around synchronization primitives, non-axis-aligned rotations, and when taking a screenshot on a nested Wayland backend.

The GL-renderer can now take screenshots using dma-backed buffers. This is for now limited to GLES 3.0 or higher, with some on going work to make that available on lower versions as well.

With this release we've introduced debug information into the GL-renderer which can be accessed by using the log scope gl-renderer-paint-nodes. Similarly to the scene-graph one, this displays the entire scene-graph alongside any potential GL-renderer optimizations being taken on that particular paint-node.

Weston 15 saw the addition of GL ES 3 texture swizzle support, which unfortunately regressed performance on platforms that do not support it. New optimizations have fixed the regression. A Weston 15 bug-fix release should also include the same fix.

API changes

What we've removed, started deprecating, and plan on removing

Starting with Weston 13, we've been adding the ability to run multiple backends simultaneously. Furthermore we've added the ability to mirror out native DRM backends to virtual types of backends (RDP, VNC, PipeWire).

The time has come to start deprecating and further remove, with a future Weston release, the remoting and PipeWire plugins, as well as the screen-share module and with it, the fullscreen shell.

All screen sharing functionality is now available by either using the mirror-of functionality or the clone-of one - if the hardware is capable of using that. Removing the plug-ins leaves no confusion towards the backends, with RDP and PipeWire being stand-alone backends, having better performance and maintenance overall. Lastly, the next release will also remove the DRM Virtual API which all these plug-ins are built upon.

On the same topic as this release, we've started deprecating non-atomic modeset with plans to remove it in the next release. Atomic modesetting was introduced 8 years ago with the Weston 4.0 release.

Breaking/required changes for users

This update further removed weston_screenshooter_shoot function in addition to screen recording with WCAP, both replaced by either the output-capture protocol or by using the PipeWire backend to record and capture an output.

Credits

Thanks to all the contributors who made this happen! As well as the contributions from various Collabora colleagues. We would like to extend our gratitude to the wider community, including the folks at Pengutronix, Red Hat, NXP, Canonical, GE HealthCare, but also to individual contributors who have been contributing and improving Weston across the board.