What Is The Wayland Display Server & Its Protocol?

While Kristian Høgsberg is now likely on his way to Toulouse, France for the 2010 X Developers' Summit, over the past day he has been working on some minor changes to the Wayland Display Server that he has now been working on for a while to leverage the latest Linux graphics technologies like kernel mode-setting and is something we initially reported on back in 2008 when it began.

Besides some very minor changes to begin supporting other types of input devices (i.e. touch-screens) by Wayland, Kristian updated the documentation to reflect the latest installation instructions and he also provided a brief description of "what is Wayland", which is copied below. There's also updates to the TODO list.

Wayland is a project to define a protocol for a compositor to talk to its clients as well as a library implementation of the protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X applications, or a wayland client itself. The clients can be traditional appliactions, X servers (rootless or fullscreen) or other display servers.

The wayland protocol is essentially only about input handling and buffer management. The compositor receives input events and forwards them to the relevant client. The clients creates buffers and renders into them and notifies the compositor when it needs to redraw. The protocol also handles drag and drop, selections, window management and other interactions that must go throught the compositor. However, the protocol does not handle rendering, which is one of the features that makes wayland so simple. All clients are expected to handle rendering themselves, typically through cairo or OpenGL.

The wayland repository includes a compositor and a few clients, but both the compositor and clients are essentially test cases.

The previous description is displayed below for reference.

Wayland is a nano display server, relying on drm modesetting, gem batchbuffer submission and hw initialization generally in the kernel. Wayland puts the compositing manager and display server in the same process. Window management is largely pushed to the clients, they draw their own decorations and move and resize themselves, typically implemented in a toolkit library. More of the core desktop could be pushed into wayland, for example, stock desktop components such as the panel or the desktop background.

The actual compositor will define a fair bit of desktop policy and it is expected that different use cases (desktop environments, devices, appliances) will provide their own custom compositor.

Of course, if you have any questions about Wayland, let us know and hopefully the interesting questions will be able to get answered this week during some after-hours talks.