What is Wayland
Wayland is a display server protocol developed for Linux by Kristian Høgsberg, an experienced X11 developer then working for Redhat.
A display server is the server side part responsible for presenting the Graphical User Interface (GUI) on a computer. Wayland will replace the X11/ X-windows based graphic architecture that has been used since 1987.
The graphics that is presented by Wayland is rendered by the client and dispatched to the server (Wayland). An application that display windows is an example of a client.
In addition to be a protocol for a display server wayland is also:
A buffert/window compositor; a Wayland display server is responsible to handle the scenegraph of graphical bufferts. Example of graphical bufferts are Windows and menus.
An event handler/dispatcher; Wayland will recieve mouse and keyboard events from the kernel and will be responsible to transform and dispatch the relevant events to clients. Wayland will for example transform global mouse coordinates (position on screen) to the local coordinations, coordinations based on the size of the client's window. Relevant events is for example keystrokes for a window in focus; this will result in a more secure architecture and make it harder for other applications to eardropp on events - a potential security risk.
Most display servers will use libinput for handling input devices.
Wayland and Rendering
Wayland is not an renderer of graphics like X11 was. The rendering of graphics like windows,menus and text is outside of Wayland's responsibility. The client has the ultimate responsibility for render its own GUI. In nearly all cases the client will delegate the rendering of GUI to one of the standard toolkits in linux - GTK, QT, ELF. All these toolkits will support Wayland architecture.
Implementations of Wayland Protocol
All the big Linux desktop environment are expected to build their own implementation of Wayland.
Weston is the reference implementation of the Wayland Protocol. Smaller desktop environments like XFCE and similar may use it.
Mutter is Gnome Desktop Environments Windows manager. With version 3.10, expected oktober 2013, Wayland will be supported. By version 3.12 expected Mars 2014 Wayland will replace X11 as the default technology.
Kwin is the KDE's Compositor and Window Manager. Wayland integration is underway and the main developer, Martin Gräßlin, is publicly commited to Wayland.
Wayland vs X11 Feature comparison
|Rendering||X11 rendering is not used any longer by X11 applications. The application does use the toolkits do the rendering and send the bitmaps to X11||Partly||No|
|Network transparancy||X11 network transparancy is only partly supported, 3D graphics and D-bus communication is for example not supported||Partly||No|
|Each frame is perfect||No graphical artifacts should occur on normal usage||No||Yes|
|Resource Efficient||Good for usage in Phones, tablets, embeded devices and TV sets||No||Yes|
|Client Side Decoration||Allows the toolkits to render window and menu decoration||No||Yes|
|Server Side Decoration||Allows Window manager, if they wish, to handle window and menu decoration||Yes||Yes|
The two features that Wayland doesn't directly support is moved to other parts of the system. So while Wayland doesn't do any rendering, the Linux toolkits will do it for Wayland.
While the rendering strategy to use in Linux with Wayland is understood and well defined, network transparancy or remote desktop for Linux with Wayland is a work in progress.
There exist an rdp (Microsoft Remote Desktop Protocol) implementation in Weston and the idea is to let the display server send compressed images, similar to how VNC works but with a more efficent implementation; the perfomance is expected to better, or at least similar to that of X11.
The recommendation, from the Wayland team, for the best performance on Network transparency, is to move Network transparency to the toolkits. A remote running application would call rendering command to its tookit, the toolkit would route the rendering command to the local toolkit that would do the rendering localy. This would be very efficent because the rendering information would be small due to that it's toolkit specific.