A few weeks ago, Weston 13.0 was released, bringing multiple fixes and important changes, notably the ability to load multiple backends simultaneously. This can be used to load VNC, RDP, or PipeWire backends for remote access alongside the native DRM backend.

Together with the ability to load multiple backends, comes the ability to have multiple overlapping outputs. This enables you to have a DRM output that is simultaneously streamed remotely via PipeWire, whilst still taking the most efficient display path. This work is not fully complete and currently requires additional code in Weston's frontend to enable, however we are looking forward to this support being seamless in the next release. This was made possible by a large-scale rework of our internal scene-graph representation and damage tracking, something which will also enable more optimization possibilities in the future.

Alongside these features, we also have been adding multiple fixes and internal changes, like pointer constraints/confined changes, refactoring the shells to make use of newer APIs, or Xwayland bug fixes and updates.

Highlights

Multiple backend support has now landed, allowing you to select backend-vnc, backend-pipewire, backend-rdp, or the nested Wayland and X11 as secondary backends. For instance, Weston can now be started like:

$ weston -B drm,rdp [without the implicit required args for rdp]

Notice that the shorter version of the backend name does not require the explicit "backend" keyword. Similarly, the shells can also be specified alike, as well as the renderers, a useful feature that landed since the previous Weston 12 release.

With this latest version of Weston, all the secondary backends like those mentioned above use the gl-renderer. Speaking of the gl-renderer, we have seen quite a few changes in this update. Optimized vertex clipping, which would give some improved performance in different scenarios, or improved GPU profiling accuracy - a feature that can be enabled using the timeline log scope, are a few of the advancements made in this release.

A new configuration entry in the ini file was added, called require-outputs which can affect how Weston treats failed enable output attempts. Normally, if Weston can not enable all outputs it finds, it would fail to start. This new entry resides under the [core] section, and can be either set to all-found, which requires being able to enable all outputs, any, which would allow Weston to start if at least an output was enabled, or none, if Weston couldn't find any outputs enabled, but would still allow Weston to start up.

Additionally, output resizing for some of these secondary backends has been added (backend-x11, backend-vnc) in this update.

On the client side, simple-dmabuf-v4l, simple-egl, simple-damage clients have received various updates: protocol, fullscreen window state support, and opaque regions.

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

In Weston 13, launcher-logind has been removed entirely, being previously deprecated in Weston 12.

libgbm 21.1.1 was already required from Weston 10, but it wasn't explicitly requested, so in Weston 13 we made it so it is now required to have it.

With the introduction of overlapping outputs and the ability to load multiple backends, we can start planning to retire the screen-share module, and with it the fullscreen-shell. Since the introduction of the kiosk-shell in Weston 9, we've worked towards replacing the fullscreen-shell with an easier alternative that doesn't require additional protocols but still retains the fullscreen window mode for clients, and that's kiosk-shell. We encourage users who haven't yet migrated to consider doing so, as we've worked towards fixing issues with it even in this Weston 13 release, like having fullscreen Xwayland surfaces or dealing with various windows states.

Breaking changes for users

With this Weston update, users of backend-vnc would need to update to Neat VNC 0.7.0.

API changes

In terms of API, the most noticeable change is the introduction of weston_view_move_to_layer(), a function that wraps the movement of a view into a specific layer. This new helper replaces several manual list manipulations, variable sets, and function calls. The single helper function makes writing your own shell or window manager easier and less error-prone.

In the previous Weston 12 release, the libweston API was also hugely refactored to use a dedicated weston_coord representation. These types make it easier and safer to deal with the different coordinate spaces we deal with in Wayland: buffer, surface, view, global, and output coordinates all have their own disjoint coordinate spaces. Although this involves a substantial change for libweston users, it should eliminate a common class of problems and make writing a window manager much more intuitive. Within this new Weston 13 release, the desktop and kiosk shell have been revamped to this weston_coord representation, while other libweston objects, like weston_output and weston_touch, are now using it as well.

Finally, in terms of API, we've added an iterator for logging scopes, called weston_log_scopes_iterate(). It can be used to list all logging scopes created by libweston components (backends, renderers, etc) such that libweston-based compositors can subscribe to them and receive debugging information.

Thanks to all the contributors who made this happen. As well as the contributions from various Collaborans, we would like to thank the wider community, and especially Michael Olbrich, Michael Tretter, and Phillip Zabel from Pengutronix, for their contributions to this release and beyond.

Related Posts

Weston 12.0: Highlights and changes for Wayland's reference compositor

Weston 11.0: what's new, what's next

Weston 10.0.1 - a bug-fix release

Related Posts

Weston 12.0: Highlights and changes for Wayland's reference compositor

Weston 11.0: what's new, what's next

Weston 10.0.1 - a bug-fix release