Wayland is the next big thing in Linux Desktop since ..the beginning? It is meant to work aside with the problematic X (with the tremendous amount of functionality) and eventually (in many years!) is going to replace it.
Few days ago Wayland released a 1.0 stable API and while GTK and Clutter have also been updated to support these changes, we have long way ahead of us to see a full Gnome support for Wayland.
Wayland
Wayland is a protocol (by Kristian Høgsberg / under MIT license) for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
So Wayland isn’t a Compositor Manager but this will be a job for Mutter. Wayland will provide a method for Mutter to communicate directly with applications and video hardware and expects him to communicate with input hardware using other libraries. Applications render graphics to their own buffers, and the window manager becomes the display server, compositing those buffers to form the on-screen display of application windows.
This is a simpler and more efficient approach than using a compositing window manager with the X, plus it gives the freedom to Gnome authors to make whatever they want with rendering, directly from openGL, as Wayland doesn’t render on behalf of the clients. It expects the clients to use whatever means they prefer to render into a shareable buffer.
Wayland promises smoother transitions and scrolling, smaller response times, better performance, easier debugging and coding for devs and in the end of the day a better Linux Desktop Experience.

Read more @ http://wayland.freedesktop.org/architecture.html
Backward Compatibility: Many toolkits will never be ported to Wayland or some applications might have X dependencies. So even if Wayland could replace X as the native Linux graphics server, X will always be there on the side, to serve those by running as Wayland Client (X on Wayland Figure).
Rather to BS you here with details – ;) – (I know what I know from docs) if you interested to learn how stuffs work you can check on Wayland Page (or Wikipedia), that provides many useful info, written in understandable way (weird for a Linux project!).
Video Cards
Wayland is not supported by any proprietary video drivers (nVidia, AMD) at the moment and you have to use the alternatives Open Source (Nouveau) or you can just buy Intel Chipsets, which their latest Ivy Bridge series simply rocks. I couldn’t find any info about that, but my guess is that eventually nVidia will support Wayland.
According to Kristian Høgsberg closed drivers need 2 things:
- A way to set the graphics mode (like KMS, but it could also be a standalone library)
- A way to share video memory buffers (for example an EGLImage) between processes
If someone knows more, please leave us a comment :)
Darxus
Darxus (I don’t know his real name) run in his blog a page about the State of Wayland which he regularly updates. Darxus also has a GTK PPA with Wayland Backend Enabled (and daily builds of Wayland) if you want to try, but I think it won’t work by default, as Ubuntu’s GTK is more updated than his package. But anyway you can try it, or build GTK (and Wayland) on your own.
Gnome in Wayland
If you Google you won’t find many information about when Gnome will fully support Wayland. So I asked Emmanuele Bassi (author of Clutter and Gnome Hacker):
The Wayland protocol has been finalized for a couple of days; both Clutter and GTK+ have been updated to reflect the current API, which means that compiling Clutter and GTK+ against Wayland should at least give you a working Wayland client backend – which means that GNOME applications should work under a Wayland compositor — assuming they don’t use X11-specific features.
There is an issue of applications using both Clutter *and* GTK+: currently, embedding GTK+ widgets inside Clutter works only on X11 because of a fast path GLX extension; the equivalent extension for EGL (which is what Wayland uses) is available for Clutter, but it’s not used in Clutter-GTK. patches are, as usual, very much welcome.
There’s also work to be done for a full feature parity between Wayland and X11 in GTK+; testing is appreciated.
Toolkits, though, are just one piece of the puzzle — the other is the compositor. mutter is very much a X11 window manager and compositor, and turning it into a Wayland compositor is not trivial. there is a branch that makes mutter an hybrid X11-Wayland compositor (X11 windows are mapped onto Wayland surfaces) but it’s experimental and needs work.
About Versions and Dates
I’m wary of giving out versions or dates; everything that follows is just my personal view as a GNOME developer.
In general, I’d say that steering GNOME towards a Wayland future means making sure that:
- All GNOME applications are not using X11-specific API, or if they are they should ensure that the GDK backend is checked and that they have fallback mechanisms in place for degrading support;
- The toolkits used in GNOME have feature parity between the X11 andWayland code paths;
- The compositor is capable of using X11, or Wayland, or both.
The devil, as they say, is in the details.
The first item in the list could be the objective of a GNOME Goal, given the project-wide scope.
About a default enabled Wayland Backend
That is a question to be posed to distributors: the packages for GTK+, Cogl, and Clutter need to be built with the Wayland backend, and a dependency on Mesa and the Wayland client library; this may or may not be acceptable.
it’s also going to be problematic if you are using a binary driver, like the nVidia and the AMD/ATi ones, as they don’t support Wayland.
Then I asked Matthias Clasen (about any available dates/versions) which is a member of Gnome Release Team and a main GTK Hacker:
You are looking for information that doesn’t exist. As Emmanuele pointed out, much of the basic infrastructure is in place, but getting the entire desktop running requires a lot more work.
Full GNOME/wayland support will happen when somebody steps up to lead that effort. Until then, GNOME runs just fine on top of X, and we’ll continue to make it better.
So it isn’t quite clear when a full Wayland support will land on Gnome. However as you can see (from the Weston figures) many Gnome Apps (not all) can run on Wayland and from Ubuntu camp there are also some good news about a Wayland support, even if experimental. There are also some distros that already ship Wayland as default (for testing). Rebecca Black OS is one such release (KDE based).
Epiphany in Wayland | by Igalia
Epiphany running on Wayland. In this case, we can see the accelerated support for CSS 3D transformations and WebGL that Jose Dapena Paz is implementing on WebKitGtk+.
Jose says:
As part of my work for Igalia last weeks, I’ve been working on adding support for running WebKit-Gtk+ on Wayland. Though making it work for standard webs was a small work, adding support for Accelerated Compositing and WebGL implied adding support for EGL, and some changes in Accelerated Compositing infrastructure to render to an EGL texture shared among web layers contexts and Gtk widget.
Source: Igalia G+
Ubuntu 12.10
I tested Weston in a Virtual Box in a Ubuntu Quantal. I just installed the latest Ubuntu to see it. Well, I never imagined how a so good distro could become so bad. Ubuntu is a commercial product (as it serves commercial purposes for Canonical) and it also poses the 80% (maybe more) of the Linux Desktop trend share. So it is Okay to be some rough with them :)
Except all issues I -unfortunately- discovered, Unity is also super slow in Virtual Box -actually you can’t even run it. Gnome Shell is kinda 20 times faster. Just for the gossip here is what Darxus said: Ubuntu has seriously lost it!





Pingback: Links 29/10/2012: Steam For Linux Beta Needs Testers, GNOME 3.7.1 | Techrights
Pingback: Gnome 3.8 Features: Port Gnome-Shell to use XI2 | woGue