Marius Vlad
February 19, 2026
Share this post:
Reading time:
On February 19th, Weston 15.0 was released, and with it came a range of new features. Let's explore what's been added.
A sought-after feature is the introduction of a new shell, called the lua-shell. As the name stands, this includes the ability to customize window management and create shells written in the Lua programming language. Whereas kiosk-shell has been great for those special-purpose limited use cases, lua-shell gives people the flexibility to make their window management completely configurable, without having to maintain whole piles of C. To better exemplify how this works, we have included with this Weston 15 release a simple tiling shell which has been added in the configuration ini file for lua-shell to execute.
Assuming you have Weston 15 installed, you can try out the new lua-shell by simply passing the shell argument:
$ weston --shell=lua
We encourage users to use that as a starting point and further expand on it when writing new shells.
One of Weston's fundamental pillars has always been making the most efficient use of display hardware. Over time, all the work we did to track and offload as much work as possible to this efficient fixed-function hardware has come at the cost of eating CPU time. In the last couple of release cycles, we've focused really hard on improving performance on even the most low-end of devices, so not only do we make the most efficient use of the GPU and display hardware, but we're also really kind on your CPU now. As part of that and to improve our tooling, Weston 15 now comes with support for the Perfetto profiler.
To be able to capture a trace see out-of-process tracing mode and also check how to visualize the trace. See as well the configuration file which you will need when capturing the trace. Note that this was tested with Perfetto v47, so newer Perfetto releases might have different methods of capturing a trace.
With this Weston release we put a huge amount of time into working on new Wayland protocols, with implementations in Weston and all over the stack. One of the most critical parts of media playback is timing the final display perfectly. Implementing these has actually resolved a long-standing issue with Vulkan clients and Wayland, where we were violating the spec by not allowing clients to pipeline frames. These protocols work together to allow better frame pacing and smoothness for clients, like games or video playback, as opposed to using the default mailbox system found in Wayland. While doing that we've also added a new set of Vulkan extensions to allow clients to have the best of both worlds: pipelining frames with Vulkan's FIFO mode, but without incurring the latency increase this usually implies.
On the High Dynamic Range (HDR) front, this new release includes an implementation for the color-representation protocol and adds support for 10-bit per channel pixel formats like NV15, NV20, NV30, and P030. The color-representation protocol is for defining YUV-to-RBG conversion and is used to send alpha-channel mode, conversion coefficients, chroma siting and quantization range for interpreting buffer contents. Both the color-representation and color-management extensions are required for proper HDR video playback, and support for them is still a work in progress. The color-representation protocol further allows to correctly render full-range YUV buffers from cameras using either the renderer or making use of hardware planes.
Still on the color-management protocol, this new release added the infrastructure to allow clients to create parametric image descriptions with on-going work required to make that fully usable.
As part of the off-load color transformations using Kernel Mode Setting (KMS), this Weston release added the ability to off-load post-blend color transformations. We are also working to be able to offload pre-blend transformations using the new kernel per-plane color pipeline uAPI. Note that a more powerful uAPI for offloading post-blend color transformations is required in order to enable direct-scanout of color-aware applications. Such uAPI is currently a work-in-progress.
A new renderer has made it into this Weston release: the Vulkan-renderer. It is currently in an experimental phase, but it has already seen a few bug fixes prior to this new release.
This allows developers to work on Vulkan driver enablement and run Weston without using an intermediary translation layer like Zink. It supports both nested (Wayland, X11) and the native DRM back-end, and it targets Vulkan 1.0 specification to allow running as many Vulkan implementations as possible.
Together with Vulkan-renderer we have a few clients as well, similar to the GL ones; simple-vulkan and simple-dmabuf-vulkan are some of the clients you can try out. Note that there's no requirement for the Wayland client to use the same graphics API as the Weston compositor.
To give the Vulkan-renderer a go, just start Weston like so:
$ weston --renderer=vulkan
This new Weston release adds a few interesting new features. One of those features is about improving accessibility by targeting color vision deficiencies such as deuteranopia, protanopia, and tritanopia. In order to address these deficiencies, color effects have to be applied using the GL-renderer on specific outputs marked as such. These color effects are currently incompatible with the color-management (and implicitly the HDR functionality) module, but that is to be fixed later. Support for the newly added Vulkan-renderer will be added in an upcoming release.
Like every new release, bug fixes are an integral part of each release, and they happen for this one as well.
The DRM back-end has been getting various improvements. Part of these changes are better allocation of hardware planes (particularly for underlays). This would allow better allocation of resources, both in hardware and software with platforms where the primary plane can be dynamically ordered between other hardware planes (i.e., AMD) can take advantage of such improvements.
On the same topic of better allocation of hardware planes, the compositor now contains a path that allows a plane-only state for situations where the client buffer does not cover the entire output. This opens the possibility to offload the background color to KMS and reduces the overall memory bandwidth.
To take advantage of this functionality today, either the shell should have a black color background, or the client needs should be in a fullscreen state. It can then use a different buffer dimension than that of a buffer that covers the entire output and Weston will attempt to lift the content into the primary plane as opposed to using a hardware overlay plane. On the same topic of efficient use of display controllers, we've also revived a kernel uAPI proposal which was stalled for a few years to allow the display controller to expose a programmable background color, as opposed to using a black color background.
Another useful feature in this release is the ability for client-allocated buffers to make use of udmabuf for taking screenshots using the writeback connector. Rather than the compositor being the one that allocates buffers, the client can use dmabuf type of buffers and achieve an effective zero-copy, including the ability to take screenshots for scanout-capable buffers.
On the same front, the DRM back-end saw a fix for the dmabuf feedback implementation, which was causing an endless feedback loop (a change that will also be part of the Weston 14 bug-fix release). A few output hot-plug changes made it as well, including support for better handling of improper or bad cable connection which might end up in an inconsistent state between the kernel and the Weston compositor.
With this Weston release basic support (game mode VRR) for Variable Refresh Rate has been added in the DRM back-end. That works on a VRR-capable DRM driver and requires setting up in the configuration file.
Beside the new Vulkan-renderer with this release our GL-renderer saw quite a few internal changes. Worth mentioning is the further work that Loïc Molinari did on improving texture and framebuffer objects handling, and with it improved read-back support.
On the same front this new release includes better handling of solid regions, an optimization useful for tiled architectures, where we were previously using a fragment shader for every pixel rather than issuing a potentially more efficient clear.
Protocol wise, the content-protection and weston-direct-display protocols have received a couple of fixes. These address some corner cases when both protocols are used together, and allow customizing the placeholder color when certain content-protection level can't be satisfied.
Weston's debug scopes can now be filtered out such that not all of them are advertised over the weston-debug protocol. Normally when specifying the --debug command line argument, all the debug scopes are advertised (including the protocol one, which might contain sensitive information from clients). With the additional -d|--debug-scopes=SCOPES command line option, you can specify which debug scopes are advertised over the weston-debug protocol extension. The Weston compositor will also print out now which debug scopes are advertised to have a visual cue on what debug scopes are actually advertised.
Many fixes have been added to the xdg-shell protocol implementation to cover some corner cases as well as fixing various back-end interactions like reflowing, resizing, or hot-plugging outputs.
In terms of the shells, desktop-shell saw some regression that got fixed with this release. All shells, including ivi-shell and the new lua-shell, now have the ability to inform the back-ends when it is the proper time to start the repaint loop. This helps out in various circumstances like a seamless transition between various Weston instances, between text to graphics mode, or in cases where we had to temporarily install a curtain to avoid passing a buffer that has never been drawn in. The latter case would have unforeseen consequences as it might be passed straight to the driver.
With Weston 15 our CI system got a few fixes and improvements. We're now using udmabuf together with vkms, and we've added a new C++ front-end which tests that libweston-based compositor can be built with C++ compiler. Still on the CI front, tests are now scoped per shell. As a result, if a maintainer or user chooses not to build a particular shell, the tests that depend on that shell will not be run.
libweston API got a few changes like private data for output management available for the shells to manage, as well as the notification mechanism mentioned previously where shells can inform the compositor when it is ready to start displaying. For more elaborate details regarding libweston changes, please see the detailed change log.
In this release fullscreen protocol has been removed from the nested Wayland back-end and with it fullscreen-shell and screenshare module have also been deprecated. We recommend switching to the kiosk-shell and 'mirror-of' for similar functionality.
We are planning on removing xdg-shell-v6 unstable in favor of the xdg-shell stable version. Many of the xdg-shell fixes have not been done in the unstable version and it doesn't make sense to keep the unstable version in the tree.
Another change with Weston 15 is that the DRM back-end's debug scope must be specifically enabled for use with the flight recorder. It was previously enabled by default, however we have changed this to improve performance.
Weston 15 now requires libdisplay-info when building Weston. libdisplay-info was mandatory for the DRM back-end prior to this change. If you do not use the DRM back-end you will now see libdisplay-info being mandatory when building Weston.
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, openSUSE, MediaTek, KDE, Gentoo, Arch Linux, and Valve, as well as individual contributors who have been contributing and improving Weston across the board.
19/02/2026
Weston 15.0 has arrived, bringing a brand new Lua-based shell for fully customizable window management, an experimental Vulkan renderer,…
18/02/2026
Collabora is excited to see Monado at the heart of the new OpenXR runtime for Android XR, a major milestone for Open Source XR interoperability.
17/02/2026
With its latest release, GStreamer adds native support for AI inference engines including ONNX Runtime, LiteRT, and Burn, along with tensor…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (0)
Add a Comment