My understanding of Wayland

Darxus at chaosreigns.com Darxus at chaosreigns.com
Fri Dec 17 17:34:25 PST 2010


I've seen and participated in a fair amount of Wayland related confusion,
so I started writing stuff up.  Please tell me where I'm wrong, and
elaborate where you can.

(Also at http://www.chaosreigns.com/wayland/ )

---------------------------------------------------------------------------
Ubuntu's Unity desktop originally had a Clutter backend. Unity is the
desktop Ubuntu announced will be moving to Wayland.

Clutter is equivalent to GTK (Gnome) / Qt (KDE).

Clutter is also the primary library for MeeGo.

MeeGo was first announced as a joint venture between Intel and Nokia. They
have said they're planning to move to Wayland.

Intel now employs Kristian Høgsberg (krh), creator of Wayland, to get
MeeGo working on Wayland.

The existing programs provided in the Wayland git repository are only
demos. "Wayland is a protocol for a [compositing window manager] to talk
to its clients as well as a C library implementation of that protocol."

X is a display server.

Compositing is the process of taking the contents of the client
application windows, applying any graphical effects, and merging them into
a single output image. It is necessary for effects like transparency,
3D rotation, and jiggly windows. When using a non-compositing window
manager, this process of creating the final image is handled by X.

Wayland exists to allow compositing window managers to communicate
directly with client applications without X. Compositing window managers
can then communicate directly with the display and input (keyboard, mouse)
hardware, becoming the display server. They are free to communicate with
the hardware however they like (so requirements for implementation are
very few), but they are likely to use KMS, EGL, OpenGL ES 2 (GLES2), udev,
and evdev. The current problem with using non-ES OpenGL is that "...libGL
pulls in GLX and all the X dependencies." There is some possibility of
creating a library to wrap these for Wayland display server compositors.

All compositing window managers I know of: Compiz, KWin (KDE), Metacity
(Gnome), Mutter (Gnome Shell, MeeGo netbook), MCompositor (MeeGo handset).

The default desktop of the next release of Ubuntu (11.04, Natty) is
planned to be Unity on Compiz instead of Clutter.

The head maintainer of Compiz, Sam Spilsbury (smspillaz), is employed by
Canonical (which owns Ubuntu). He has been working on moving X11 stuff
out to a plugin to make it easier to use Wayland or Haiku instead.

I believe the only requirement for implementing Wayland is the ability to
allocate a shared memory (SHM) buffer (bitmap, collection of pixels) *or*
DRM buffer, and pass a handle to that buffer from client applications to
the display server compositor. This is the (only) way clients communicate
their graphical contents to the display server. The buffer is allocated
by the client.

A DRM buffer exists in the memory of the video card, which allows
more efficient compositing. When using DRM (Intel, ATI(AMD), nVidia),
clients write their graphical contents directly to video card memory,
then tell the Wayland display server that it has been updated, then the
Wayland display server recomposites the screen.

It is expected that Wayland will be implemented in all major graphics
libraries, primarily GTK (Gnome) and Qt (KDE). Preliminary support has
already been created for both (as well as Clutter). Most programs use
one of these two libraries, so they will get Wayland support through
them without modification. Qt already supports switching outputs between
X and Wayland at runtime using the -platform command line option, so
applications will not need to be recompiled to switch between them. It
is my personal expectation that all graphics libraries that support
Wayland will become capable of detecting the availability of Wayland or
X automatically and picking the protocol at run time without any input
from the user.

X.org (the Linux X server) has already been modified to function as
a Wayland client, rootless or not. This means applications which only
support X (either due to being run over a network, or lacking any Wayland
support) will look just like any application connecting via Wayland,
with their own window (the meaning of "rootless"). Currently, this only
works on Intel video cards.

So applications that support Wayland will still be able to connect to
X servers, and applications which do not directly support Wayland will
be able to connect to it through an X.org Wayland client.

I also personally expect that X.org will start automatically only when a
client attempts to connect to it, as is the case with XQuartz / X11.app,
which includes X.org, bundled with MacOS.

So it is likely that you won't even be able to tell if your using
Wayland or X without digging, even if you use applications that don't
know about Wayland.

There is an Ubuntu Wayland PPA (set of packages).

Ajax, a major Fedora developer, has created a Fedora package of Wayland.

Clutter's output is via cogl.

"Mutter is the Short form of Metacity Clutter". Mutter was a fork of
Metacity using Clutter for output.

"Mutter will be the primary window manager for Gnome Shell desktop"

Gnome Shell is a Mutter plugin.

Unity has become a Compiz plugin.

LLVMpipe is a software implementation of OpenGL for use with graphics
cards without 3D acceleration, which is much faster than Mesa's previous
software implementation.

KWin is now doing output via OpenGL ES to make it easier to switch
to Wayland.
---------------------------------------------------------------------------


What functions are used to allocate the SHM and DRM buffers?

-- 
"Government is not reason, it is not eloquence, it is force; like fire,
a troublesome servant and a fearful master. Never for a moment should
it be left to irresponsible action." - George Washington
http://www.ChaosReigns.com


More information about the wayland-devel mailing list