Testing GNOME Shell as a Wayland compositor

Prerequisites

• wayland
• mesa, with --with-egl-platforms=x11,wayland,drm; if you want weston, add --enable-shared-glapi --enable-gles2; if you want DRM, add --enable-gbm
• cogl, with --enable-xlib-egl-platform --enable-wayland-egl-platform --enable-wayland-egl-server; if you want DRM, add --enable-kms-egl-platform
• clutter, with --enable-x11-backend --enable-wayland-backend --enable-gdk-backend --enable-wayland-compositor; if you want DRM, add --enable-egl-backend --enable-evdev-input
• weston
• mutter, wip/wayland branch, with --enable-wayland --with-wayland-protocols=$(path to weston source checkout)/protocol
• gnome-shell, wip/wayland branch

• XWayland - see instructions at http://wayland.freedesktop.org/xserver.html#heading_toc_j_1

• the matching X driver for your card, built with XWayland

Running nested as a subcompositor

You can run "mutter --nested" from an existing X11 or wayland session, and it will open a window, within which you will have XWayland and Wayland clients. This is the easiest way to try Wayland support right now.

You cannot use this mode to run gnome-shell, unless you also open a new dbus session with eval $(dbus-launch --sh-syntax) or something similar.

To open a nested gnome-shell session in Wayland do:

dbus-run-session -- gnome-shell --nested --wayland

This allows useful set ups such as multimonitor and different scales, for example, to run two monitors with a DPI scale of 1 for the first and DPI scale 2 for the second:

dbus-run-session -- env MUTTER_DEBUG_NUM_DUMMY_MONITORS=2 MUTTER_DEBUG_DUMMY_MONITOR_SCALES=1,2 gnome-shell --nested --wayland

Resolution of each can be adjusted in the GNOME control center inside that session.

Note: the Intel (i965) driver is terribly broken under EGL-X11. If you patch Cogl not to crash under software rendering (bug 704750), you may get xwayland to run by forcing the wlshm driver (but that's broken on its own, as seen from wayland-devel archives). Alternatively, if you have a recent enough Intel card (gen >= 6, ie sandybridge or better) and you patch mesa to install it, you can run the ilo driver, by replacing ilo_dri.so to i965_dri.so in $(libdir)/dri. Among all attempts I made, this one got me the best results.

Note 2: the above is actually true only if you attempt to resize the clutter window, ie if you are testing the display configuration API. If you stick to the default 1024x768, i965 works fine.

Running on bare metal as root

If you are fine with running your session as root, you don't need any special change, but you must set CLUTTER_BACKEND=eglnative and CLUTTER_INPUT_BACKEND=evdev, otherwise clutter will complain that it doesn't find a display. You can also run gnome-shell, as "gnome-shell --display-server".

Note: jhbuild does not like being run as root, but sudo and su clean the environment, so you need to patch jhbuild so that it starts as root, and then run "sudo jhbuild -f $HOME/.config/jhbuildrc shell".

Note: there is no code in wip/wayland to handle DRM master, but if you are running mutter this way Xorg will fail to set master if you attempt to switch VT, which will crash it and tear down your entire session.

Running on bare metal as a regular user

Unlike weston, mutter in the wip/wayland branch does not support running on bare metal as a regular user. Instead, you can choose the wip/wayland-2 branch to run under weston-launch. You still need to patch weston-launch so that it runs mutter instead of weston, and you probably need to patch away the environment cleaning too, if you're running off jhbuild.

Note: weston-launch as shipped in Fedora 19 has a conflict with the default PAM configuration (caused by pam_loginuid.so, but I don't know the actual reason), and will refuse to launch anything, so you must use a patched weston-launch.

Note: you must set -t /dev/tty* when running weston-launch, otherwise mutter fails trying to open the DRM device.

Caveats (in random order)

• Wayland windows cannot be resized
• There is only one 1024x768 output at any time, and that's hardcoded
• In wip/wayland there is no code to put the keyboard in raw mode or the terminal to KD_GRAPHICS, so input still goes to the terminal, and you get random characters in your wayland apps
• In wip/wayland-2 the keyboard and TTY are correctly configured, but for some reason libxkbcommon fails to load the XKB rules (without any log at the highest debug level) so all modifier keys are broken

• When running under X, depressed modifiers (like Shift) work fine, but the locked ones (like CapsLock) don't