What’s New in Wayland and Weston 1.11

June brings us a fresh new release of the Wayland display protocol and it’s reference implementation named Weston. This post will take a look at some of the biggest new features and improvements in the 1.11 release.

Wayland

It’s been five and a half years since Wayland was declared stable with its 1.0 release. Specifically, this meant that the core of Wayland transitioned to a policy of “no backwards incompatible protocol changes”, and it was ready for developers to use it in production systems. The years since have seen all three major Linux desktop environments create successful implementations of Wayland in addition to a few mobile platforms and innumerable embedded systems.

With the protocol being stable, most of Wayland’s core changes are bugfixes and copy edits. But lately, it seems the needs cropping up from production deployments have led to more significant changes being proposed and introduced. The 1.11 release brings three such changes.

First, proxy wrappers were introduced; these help avoid race conditions in multi-threaded clients. A new proxy wrapper API has been added for the client, which¬†doesn’t proxy events, to use when sending requests. This helps avoid scenarios where one thread causes events to be dropped before they can be handled by other threads. Tests have also been added to verify functionality, and the new functionality is now used to fix a race condition present in wl_display_roundtrip_queue().

Wayland’s shared memory (shm) received several improvements. When undergoing a resize operation while external users are holding references to it, the resize is deferred to prevent a crash; Wayland now counts external and internal users differently to permit the tracking of this. Other invalid situations during resizes now emit better warnings to the log and properly clean up their memory allocations.

As part of Wayland’s ongoing work to improve enum for language bindings, support for cross-interface enum attributes has been added. This allows the documentation to reference enums defined in other interfaces using a dot notation.

Along with these three technical enhancements, the protocol documentation received some deep copyediting attention. A very important aspect of the protocol is described in its description: both the server-side and client-side are intended to be implementable by third-parties so the documentation of how their APIs should behave must be communicated precisely and unambiguously; thus the documentation improvements in this release are notable.

Additionally, documentation now includes HTML generation of doxygen comments in the source code. This provides client-side and server-side API documentation which provides developers with easier web-based reference for Wayland’s functionality. Each protocol gets a separate doxygen @page, and each interface its own @subpage; in the case of Wayland, there is just the one core protocol, but for the wayland-protocols package this will organize the various content better since each one will have a fixed HTML file name that it is directly linkable/bookmark-able. A few configuration settings for doxygen were tweaked to enable better scanning of C code.

Weston

Weston is a reference implementation of the Wayland protocol, developed primarily as a technology showcase. With that said, there is interest in using it or its internal components for various production purposes.

To facilitate this work, Weston’s internals are being refactored to provide a library API, ‘libweston’. While actual usability still lies somewhere off in the future, 1.11 marks a big first step. As part of a concerted effort to push the libweston development along backend configurations have been reworked to permit them to be initialized independent of Weston’s main.c. This was a relatively major change this cycle that restructured the setup logic for most of the backends and added a new backend loading routine. Config parsing is still done in main.c, but the config data is passed as a structure to the – dynamically loaded – backend module and used or copied into its internal data storage (the config object provided by main.c has a lifetime that ends at the completion of initialization). This structure is defined in a header and versioned to enable compatibility validation between the frontend and backend. The following backends received this treatment: wayland, drm, x11, headless, fbdev, and rdp.

Another major area of development focused on the IVI shell and related code. Huge amounts of cleanup, refactoring, and documentation copyediting are helping polish this codebase. A large number of unnecessary API calls were dropped or simplified. Limitations such as seat handling were improved or at least worked around to avoid crashing or other misbehaviors, and dynamic memory allocation was changed to use the stack where possible. NULL pointer checks were added for sanity checking in some APIs, and dropped where not strictly needed. Configuration calls from ivi-layout.c to ivi-shell.c were straightened out, allowing configure events to be sent more directly. Some attention was also given to fixing builds against FreeRDP 2.0; this is still not 100% completed yet, but is moving closer. More patches are already in the queue to help get Weston running properly on this platform.

A number of other build system enhancements landed. Various Weston dependencies including WebP and jpeg have been made optional to permit Weston to be brought up on systems with a more stringent sets of packages. Along with this are various other cleanups to build logic and improved detection of available libraries and versions. Of particular note, previously Weston had separate version checks for libwayland-client and libwayland-server, but now a single version is assumed for both; it would be a highly unusual configuration to be building or using Weston with non-synchronized versions. Finally, there have been a number of crash bug fixes and the usual vast number of minor changes.

Looking Ahead

A number of new optional protocols or enhancements to existing protocols are already in the works. Most of these will be making their appearance in the wayland-protocols package rather than Wayland itself, but regardless, there may be Weston implementations of these in the 1.12 timeframe.

The xdg-shell protocol is poised to move to version 6 to help incrementally advance API standards across desktop environments. A tablet protocol and corresponding Weston implementation will improve user experience with these input devices. The text input protocol is going to be revved up with several fixes to make it more useful in real world applications.

Despite the relatively short window of time for landing features for 1.12, it could well reach the stature of 1.11 in terms of number of features and major changes.

Author: Bryce Harrington

Bryce is a founder and developer of the Inkscape project, but began his career in the aerospace industry as a spacecraft propulsions engineer.

One thought on “What’s New in Wayland and Weston 1.11”

Comments are closed.