Wayland Background

Ubuntu's Unity desktop originally used the Mutter window manager, which has a Clutter backend, for Maverick (10.10). Unity is the desktop Ubuntu announced will be moving to Wayland.

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, and 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 (as the demo compositor does). The current problem with using non-ES OpenGL is that "...libGL pulls in GLX and all the X dependencies." "the faq doesn't say you can't use GL with wayland, it just says that there's currently no way to link to libGL.so without pulling in X deps" There is some possibility of creating a library to wrap these for Wayland display server compositors.

OpenGL ES is a subset of OpenGL intended for Embedded Systems, which is widely supported.

All compositing window managers I know of, the primary candidates for becoming Wayland display servers:
Compiz, KWin (KDE), Metacity (Gnome), Mutter (Gnome Shell, MeeGo netbook), MCompositor (MeeGo handset), Xfwm (Xfce).

Since Gnome is replacing Metacity with Mutter in Gnome 3.0, it is nolonger being maintained except for bug fixes.

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

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 Compiz plugin to make it easier to use Wayland or Haiku instead. He was annoyed that GNOME Shell was implemented as a Mutter plugin, and pleased that Unity on Mutter was not implemented as a plugin, but now Unity is a Compiz plugin.

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 output 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 directly in video card memory.

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 x11" / "-platform wayland" (SHM) / "-platform waylandgl" (DRM) command line options, so applications will not need to be recompiled to switch between them. GTK has preliminary support for multiple backends as of December 2010, specified by setting the GDK_BACKEND environment variable to x11 or wayland. 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 X server commonly used on Linux) 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 you're using Wayland or X without digging, even if you use applications that don't know about Wayland.


More fragmented facts.

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".

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.

<krh> maelcum: [Intel] 855 is not supported
<krh> the hardware is just too old
<krh> the 8xx intel chips don't work well with gem
<krh> the caching interaction between gpu and cpu isn't understood well enough
<krh> and even inside intel, nobody really knows how it works anymore

<maelcum> krh: while you're here, what is missing in qt-wayland?
<krh> mainly gl integration
- 2011-01-03

Clayland is library for integrating Clutter and Wayland (which includes a demo compositor), which may be folded into Clutter, maintained by Kristian. (git repo, screenshot)

It looks like Ubuntu Natty 11.04 (the next release, for April) will include all build dependencies for Wayland. Those not yet in Natty are in the xorg-edgers PPA, and cairo from the wayland PPA, which should all be in the Natty archives by next week (January 29th). I'm still hoping for a wayland package as well (in universe).

<krh> I think the sample compositor could live on as a simple core compositor with a pluging architecture
<krh> and then that would be the answer when people want to run awesome or openbox or such with wayland: write a plugin to implement that behaviour in the sample compositor
<Darxus> krh: Awesome and openbox being examples of non-compositing window managers?
<bnf> Darxus: yes
<krh> Darxus: it was more an example of standalone window managers without an entire desktop environment


The compositor program from the Wayland git repo has three modes, DRM used outside of X ("the drm compositor"), X11 used inside of X ("the x11 compositor"), and a wayland mode for running the wayland compositor as a client of another wayland compositor.


2012-04-15
<brokenshakles> Does wayland output to a Getty?
<brokenshakles> Or is it like DirectFB and output to a kernel framebuffer?
<pq> brokenshakles, neither to be exact, the drm backend uses KMS API
<brokenshakles> Ah, so KMS in of itself is a new type of interface?
<pq> brokenshakles, yes, it replaces the legacy fbdev kernel interface


03:38AM <pq> I still expect all the backend and input driver efforts to eventually concentrate into a single system compositor project, and then all "user compositors" will simply talk Wayland and probably use EGL/GL for rendering.


08:56AM <krh> I've been using weston as my main desktop for a couple of weeks now
09:05AM <krh> Darxus: I'm even using weston-terminal now (which explains all the recent terminal fixes :)


2012-09-25
03:12PM< pierrevr> Hi, I have a question about remote wayland... has anything been started on this level since the failed attempt of last year's gsoc ?
03:16PM< krh> pierrevr: yeah, I have a proof-of-concept running
03:17PM< krh> Darxus: watch the end of the wayland talk from XDC
03:18PM< knurd> Darxus, starts at timecode 1:11:50 iirc
03:20PM< Darxus> http://www.youtube.com/watch?v=L8zwnqKysfI Looks like it.

04:16PM< wm4> will Wayland be able to run on BSD natively?
04:16PM< krh> if somebody ports it (and kms and gem/ttm and mesa etc)
04:17PM< psychon> will wayland solve world hunger?
04:17PM< krh> though a sw renderer on /dev/fb is also possible


09:05AM < pq> dv_, EGL needs to know about Wayland, because libEGL needs to be able to talk the Wayland protocol to


Wayland
Thu Apr 11 09:06:21 EDT 2013