With Wayland 1.0, A Large TODO List Remains

Wayland 1.0 will be released as soon as today, but this doesn't mark the death of X11 and Wayland beginning to secure major traction on the Linux desktop.

Kristian Høgsberg, Wayland's creator that began coding this likely eventual X.Org Server replacement back in 2008 and was first publicly covered on Phoronix, has always reinforced since earlier this year when planning the 1.0 release that this won't mark a point of domination on the Linux desktop. Wayland 1.0 simply marks the point at which Wayland developers will ensure backwards compatibility with the Wayland core protocol and API. If your tool-kit or application is targeting the 1.0 API/protocol, it will work with future versions rather than in the pre-1.0 state where there was significant breakage without notice.

Breakage just in recent days with Wayland has caused clients to no longer work. The latest Mesa 9.0 release won't even work with Wayland 1.0 but it will be a few weeks before Mesa 9.0.1 gets released with Wayland 1.0 compatibility. Tool-kits and other applications need to be updated for the final pre-1.0 changes.

When there is this protocol and API stability, application developers can now be more convinced to support Wayland, but still there is lots of work still ahead on Wayland itself and the reference Weston compositor implementation.

Kristian updated the Wayland TODO list today to reflect some items that have been addressed, but still the TODO list is lengthy to tackle in the post-1.0 era. The TODO list can be seen from the Git web interface while below are some of the highlights.

- Remote Wayland support / "network transparency", as has been widely talked about. Kristian has already worked on code in this area as he showed off at XDC2012, but he hasn't yet released the patches as he wants to make sure his design and code is in good shape before it sees the public spotlight.

- MIME-type guidelines support for data sources with regard to Drag-n-Drop and selection handling.

- Due to client side decorations, there needs to be a protocol for specifying title bar rectangle and the regions for the close button so that there can be a pop-up force-close dialog if applications don't respond to ping events.

- Pop-up placement protocol logic.

- Clone mode ("presentation mode") for displays.

- Support for sharing buffers from the compositor to clients.

- A glyph cache.

- A potential Wayland settings protocol for telling clients about themes, font details, and other information.

There's also much work to do on the client end of finish porting potential tool-kits to Wayland, various other applications, etc. There's also a potential TODO item about investigating support for DirectFB with Wayland.

If you missed it, see the Wayland Prague presentation from LinuxDays this past weekend.