Wayland Rendering
7
window is only restricted to what the compositor can do, as long as it can compute the inverse
transformation for the input events.
3. As in the X case, when the client receives the event, it updates the UI in response. But in the
Wayland case, the rendering happens in the client, and the client just sends a request to the
compositor to indicate the region that was updated.
4. The compositor collects damage requests from its clients and then recomposites the screen. The
compositor can then directly issue an ioctl to schedule a pageflip with KMS.
3.2. Wayland Rendering
One of the details I left out in the above overview is how clients actually render under Wayland. By
removing the X server from the picture we also removed the mechanism by which X clients typically
render. But there's another mechanism that we're already using with DRI2 under X: direct rendering.
With direct rendering, the client and the server share a video memory buffer. The client links to a
rendering library such as OpenGL that knows how to program the hardware and renders directly into
the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the
desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and
when and where it has rendered new content into it.
This leaves an application with two ways to update its window contents:
1. Render the new content into a new buffer and tell the compositor to use that instead of the
old buffer. The application can allocate a new buffer every time it needs to update the window
contents or it can keep two (or more) buffers around and cycle between them. The buffer
management is entirely under application control.
2. Render the new content into the buffer that it previously told the compositor to to use. While it's
possible to just render directly into the buffer shared with the compositor, this might race with
the compositor. What can happen is that repainting the window contents could be interrupted by
the compositor repainting the desktop. If the application gets interrupted just after clearing the
window but before rendering the contents, the compositor will texture from a blank buffer. The
result is that the application window will flicker between a blank window or half-rendered content.
The traditional way to avoid this is to render the new content into a back buffer and then copy
from there into the compositor surface. The back buffer can be allocated on the fly and just big
enough to hold the new content, or the application can keep a buffer around. Again, this is under
application control.
In either case, the application must tell the compositor which area of the surface holds new contents.
When the application renders directly to the shared buffer, the compositor needs to be noticed that
there is new content. But also when exchanging buffers, the compositor doesn't assume anything
changed, and needs a request from the application before it will repaint the desktop. The idea that
even if an application passes a new buffer to the compositor, only a small part of the buffer may be
different, like a blinking cursor or a spinner.
3.3. Hardware Enabling for Wayland
Typically, hardware enabling includes modesetting/display and EGL/GLES2. On top of that Wayland
needs a way to share buffers efficiently between processes. There are two sides to that, the client side
and the server side.
On the client side we've defined a Wayland EGL platform. In the EGL model, that consists of the
native types (EGLNativeDisplayType, EGLNativeWindowType and EGLNativePixmapType) and
a way to create those types. In other words, it's the glue code that binds the EGL stack and its