This post will take a look at the current state of upstream Wayland as the community prepares for the upcoming 1.9 release. The core of the project is quite mature and is currently in a holding pattern as KDE, GNOME, EFL, and others complete their Wayland transitions. As this proceeds the Wayland community will be responding to the needs of these other projects.
Most notably, there is a need to complete the XDG Shell protocol. This aims to become a standard across all desktop environments, but it needs to have strong buy in and collaboration from the desktop environment projects themselves. There’s a number of conversations that need to occur before anything can be nailed down effectively, but the desktop environment developers need to be relatively far along in their implementations before they can have strong enough opinions on what the desktop API should look like.
There are several bugs in Wayland that are currently under investigation.
Buffer Race Condition
The first is a race condition with buffers that have been attached by two or more surfaces that have issued commits. When the release is received by the client, it’s unclear which surface’s commit is being processed, and whether the other surface’s commit is still going to be honored.
One solution is to allow clients to do reference counting for the commits. An alternative approach would prohibit commits on a buffer that has already been reserved by the server. Either solution will require some care during implementation to avoid incompatibilities between different versions of clients and servers.
EGL Damage Reporting
Second is a heavily discussed damage reporting issue when using EGL. The wl_surface protocol requires that damage is reported using the surface’s coordinates; this allows for only the damaged area to be repainted. However, EGL isn’t able to account for transformations done to the surface’s buffer. For example, if the buffer is rotated 90 or 270 degrees, the damage is reported incorrectly; this rendering issue would show up when resizing a rotated window.
Mesa deals with this by selecting as big of an area as it can (far larger than the window itself). This works, but it’s excessive. Other EGL implementations set the damage rectangle to be the buffer size (thus under-damaging if the buffer is rotated).
Several solutions were considered, but they all had one problem or another. Currently, the favored solution is to enable Wayland to communicate damage in buffer coordinates rather than surface coordinates. The old system would still be available for legacy purposes, but as EGL implementations are migrated to this new API applications and compositors will be able to take advantage of the better damage handling solution.
wl_display Race Condition
The third major issue is another race condition, this one is related to the wl_display object when using non-default proxy queues. The issue is that in the span of time between when the wl_callback object is called and when it sets its queue, another thread could submit events, causing the first to be dropped completely.
Two solutions have been proposed. The first is to combine both the wl_callback object call and the queue setting into a single API call. The other approach proposes adding a proxy wrapper object that allows for the definition all the object’s properties before creating it. Then, queues are added and the original object can be unwrapped at any time to add listeners. An RFC for this latter solution was proposed June 29th.
The fourth major issue is pointer-lock. This feature provides the ability to get relative pointer motion without actually moving the cursor visibly. A related concept is pointer-confinement, which allows constraining the mouse cursor and prohibiting from entering certain areas of the screen (or blocking it from moving to certain off-screen areas). Both features allow the client to grab the pointer device, but only in response to some user action. Pointer lock is an important feature for games, and potentially certain Xwayland use cases. For example, in a game, the cursor should hit the edge of the screen and stop, but motion events should still be communicated to allow the map to be scrolled. A large patchset was recently submitted to implement this in Weston’s clients.
All of these issues will be further investigated and worked on in the coming months.
Using Weston to Make Wayland Better
Looking at the R&D being done in Weston, there are two pieces that look ripe for moving into Wayland: wl_scaler and presentation feedback. Both of these need wider review before landing. At this point, even comments of “Looks Good To Me” would be valuable to develop consensus before moving forward. The other part of presentation is presentation queuing; already the review process has suggested a redesign may be required.
Developing Cutting-Edge Technology with Weston
Weston is our reference implementation of Wayland, and part of that role includes serving as an incubator for new technologies.
Atomic Mode Setting
One of these technologies is atomic mode setting support. Currently, when you set your monitor resolution, it takes several distinct operations to connect CRTCs to outputs, set encoder properties, switch graphics modes, etc. and these can cause flickering and risk some fairly severe bugs. With Atomic KMS, all of the properties are changed via a single ioctl call. If it fails, the whole thing fails and the system is left in its original state. If it succeeds, everything switches instantly, seamlessly, and glitch-free.
The Atomic KMS support has not yet landed in Weston, but the patches are under review. To a large degree this work tracks upstream kernel development, which is still ongoing. This will enable Weston to do dynamic mode setting, and will add hardware overlay support. This is essentially an extra hardware-level compositor which is useful for video players that need efficient scaling or color space conversion for windowed playback. The most important aspect of this is it enables the configuration of all of the overlay planes in a single call, so every frame is perfect even when there are multiple planes to wrangle. Atomic KMS is not strictly required by the Wayland protocol, but it’s expected that this will be the standard way that all Linux-based display servers will shift to for making the best use of the display hardware.
Wayland dmabuf Protocol
Another upcoming technology that will be incubated in Weston is the Wayland dmabuf protocol. This enables a zero-copy pipeline from video source to display. It’s hoped this will be a powerful and flexible solution for a variety of accelerated video handling such as media appliances and smart TVs, but there are still many open questions about how to best tie everything together.
Looking at Weston itself, a major technical change currently under development is libweston. This changes Weston to be not only a basic composited desktop environment itself, but to also provide a library that other folks can use to build their own compositors. We don’t expect to see this used by the GNOMEs, KDEs, and EFLs of the world; instead we’re targeting it to be a lightweight and experimental Wayland-based window managers.
Currently, some of the prep work for libweston has landed in Weston. We’re leaving its API as experimental for now, as we want to leave room for redesigning it as needed; this means there’s no API/ABI guarantees just yet. Some of the changes will be included 1.9, but it doesn’t appear we’ll have a usable libweston.so just yet.
Upcoming 1.9 Release
Wayland/Weston 1.9 is scheduled for release by the end of September. We expect the release process will be smooth, and it doesn’t appear there will be any last-minute changes or release-blocking bugs to worry about.
1.9-alpha in mid-August√ 1.9-beta in early September√
- 1.9-rc1 in mid-September, with rc2 only if necessary
- 1.9.0 by the end of September
We continue to have a fairly lengthy patch review queue. Patchwork has helped, especially with managing the smaller patches, but reviewer time is still a limiting factor. Anyone can review, and everyone *should* review. Even just “looks good to me” can be really helpful, as it helps flag patches that can be landed quickly. There is a newer version of Patchwork available that makes it easier to track review status and to handle multi-patch patchsets; it would be very nice to get this updated on FDO (hint hint!)
Onward Towards Wayland on the Desktop!
A lot of people are anticipating Wayland on their desktops. For now, we remain in a holding pattern while the DE developers roll out their Wayland support, but some of these efforts are reasonably mature enough now. The question starts to become whether there is an adequate ecosystem of Wayland enabled client applications. For things that can’t simply be moved to Wayland, the question is if Xwayland will be up to snuff. Exploring this space will take some pioneering spirits.
Speaking of Xwayland, we need a new person to help push Xwayland forward. This job involves feeding Keith Packard pull requests for collected patches. For example, there is touchscreen support not yet merged but that’s ready for landing. If this is something you might be interested in getting involved with, or if you have any interest at all in keeping up with Wayland development, you can join the wayland-devel mailing list, or join us in #Wayland on freenode.