Now that 2015 is deader than XFree86 and the year of the Linux desktop is finally here, I’m sure everyone’s wondering what 2016 will bring for Wayland…
Sometime in mid January the 1.10 alpha release is coming, with a 1.10 release to follow in February, and this is already shaping up to be a pretty beefy release.
New and Improved
Here are some of the new core Wayland features that have already landed:
Release requests for wl_seat – This is a step towards fixing a long standing problem. With no proper release request, it’s been impossible for the compositor to delete a wl_seat. This seems like it shouldn’t be a big deal until you consider the RDP (Remote Desktop Protocol) compositor, which creates a new seat for every login. Without a way to release seat resources completely, it effectively leaks seats.
wl_surface.damage_buffer – This new request (already supported in Weston and EFL) allows an application to specify its surface damage in buffer coordinates instead of surface coordinates. This should be easier for toolkit authors to use than the original wl_surface.damage request because wl_surface.damage requires coordinates in surface coordinates. Surface coordinates change when you use certain Wayland features like viewports and buffer transforms, but an application may still be easily written using buffer coordinates. Additionally, some libraries currently can’t do partial damage correctly (I’m looking at you, Mesa) because they don’t have enough information to translate between buffer and surface coordinates themselves.
SHM buffer reference count API – When a Wayland client dies, libwayland-server automatically cleans up all its resources. This results in any shared memory pools being destroyed because their reference counts drop to zero when their buffers are all gone. Enter Enlightenment’s asynchronous renderer. Wayland event dispatch still takes place in the background while the compositor is drawing the contents of shared memory buffers on screen; if the dispatch results in a client being cleaned up, shared memory can be unmapped while the rendering thread is trying to use it. Now, Wayland has an API that allows a compositor to take a reference of a shared memory pool and release it later. Enlightenment can now reference all pertinent pools before the rendering thread begins its redraw, and release them afterwards.
Heres a couple of minor items that have been added:
- Enums and bitfields have been added to the protocol specification XML, allowing people who write language bindings for strongly typed languages to sleep better at night.
- The protocol scanner (the tool that turns protocol XML files into code) now validates the XML files against the DTD file. OK, maybe this isn’t juicy, but catching protocol syntax errors before they’re published is a big win.
It’s also quite likely these will make the cutoff:
Proxy version API – This API lets a client discover the version of a protocol object it has on hand. Since you specify the version you’re binding when you request the object in the first place, this sounds a bit silly. However, a library like Mesa has no idea whether the surface it’s rendering to is new enough to support wl_surface.damage_buffer without it. The proxy version API combined with wl_surface.damage_buffer will finally allow eglSwapBuffersWithDamage() to work efficiently, instead of ignoring the passed damage and damaging the entire surface.
Pointer locking/relative pointer – This one’s been on the horizon for a few releases now, and is mandatory for Wayland to provide any kind of reasonable gaming experience. It will allow a client to lock a cursor to a position inside its window and receive relative motion events instead of absolute ones (that is, “the mouse cursor just moved +3 pixels along the X axis, -7 along Y” instead of “the mouse cursor is at 123, 99”). This should make implementing first person games on Wayland possible, and there’s a strong possibility that this will finally land (in wayland-protocols with a Weston implementation) for 1.10.
Pointer Frames – A new method of grouping together contemporaneous input data is almost ready to land. The pointer.frame event will be emitted at the end of a group of pointer events to indicate they happened at the same time; this makes writing extensions that add new pointer information easier.
Another interesting thing has happened; a new repository has been created: wayland-protocols. For some reason, this seemed to trigger a lot of apprehension and some saw this as a fork/fragmentation/problem. However, I think everyone who actively works on Wayland considers this split a good thing. Landing a protocol change in the Wayland repository is hard because anything placed there needs to be stable with long term support. Landing a change in Weston might be less daunting since we don’t have quite as firm long term promises for protocol there, but it’s still a rough process. Until this new repository existed, Weston was where a lot of Wayland protocol was born and raised, but not all protocols in Weston are destined to be part of the core Wayland protocol (weston-test for example). The Big Desktop guys (GNOME, KDE, Enlightenment) may want to collaborate on protocol without the burden of a Weston implementation, so using Weston as a protocol breeding ground is a concept that no longer scales.
So, wayland-protocols was born with the intent to speed up protocol development a bit, while keeping it reasonably collaborative. Nobody’s being shut out, nor is this some devious shift in political power; it’s a really positive step forward.
Wayland’s Slow March to Your Desktop
I think the 1.10 release of both Wayland and Weston is going to be a really good one as a result of the high number of bug fixes and cool new features. Wayland’s adoption on desktop environments continues ahead slowly; GNOME’s had a presence for a very long time with Enlightenment coming to the table a little more recently, but the KDE camp really hasn’t shown a lot of interest. However, we’ve recently seen some participation from KDE (an RFC protocol for tracking wl_seat idle times), and they’re obviously interested in sharing code they think could be helpful to other Wayland implementors.
I don’t know if that means we’re closer to a shared xdg-shell implementation, but maybe we’re at least on the way to having a common way to open a window. :-)