Bionic Beaver, the codename for the next Ubuntu LTS release, is due in April 2018 and will ship with both the traditional Xorg graphics stack as well as the newer Wayland based stack, but Xorg will be the default.

17.10, released in October 2017, ships with the Wayland based graphics server as the default and the Xorg based equivalent is available as an option from the login screen. When we started out on the GNOME Shell route for 17.10 (Artful Aardvark) we knew that we needed to have Wayland as the default option otherwise we wouldn’t know if it would work well for our users in the LTS only 6 months later. The LTS is supported for five years meaning that we need to be certain that what goes out the door on release day will be maintainable and sustainable for the duration and will serve all our users and customers needs, which is no mean feat.

As we are roughly half way through the Bionic development cycle, the time was right for us to review that decision and make a call on whether or not Wayland is the right default display server for Bionic. We have decided that we will ship Xorg by default, and that Wayland will be an optional session available from the login screen.

Why opt for Xorg by default? There are three main reasons:

Screen sharing in software like WebRTC services, Google Hangouts, Skype, etc works well under Xorg.

Remote Desktop control for example RDP & VNC works well under Xorg.

Recoverability from Shell crashes is less dramatic under Xorg.

The first two are closely linked. Wayland & GNOME Shell have a good plan in PipeWire and a Wayland protocol to provide a screen sharing service. This will take some more time to develop and there will be some lag while application developers include support in their services. Until that happens, Xorg is necessary for people who need screen sharing features. If you don’t need screen sharing features and prefer a more secure environment then the Wayland session is available for you, pre-installed.

The third point is about what happens when things go wrong. The architecture of GNOME Shell and Mutter is such that a GNOME Shell crash will end your whole session, killing running applications and returning you to the login screen. When using Xorg, the shell can restart independently of the display server and running applications. This means that once the shell is restarted, you can pretty much pick up your session from where you left off, with your applications still running.
There are two solutions to this problem when using Wayland: make sure the shell doesn’t crash or change the architecture. Both of these are work in progress and we continue to contribute to this work upstream. GNOME Shell 4 will bring a new architecture where there will be more flexibility in components restarting without affecting other components. But in short, we remain committed to GNOME and the GNOME stack and will continue to actively contribute to Wayland by adding features and fixing bugs.

The Wayland session will still be available, pre-installed, for people to use, but for our ‘out of the box’ users the Ubuntu experience needs to be stable and provide the features they have come to expect and use in daily life and Xorg is the best choice here, at least for 18.04 LTS, but for 18.10 we will re-evaluate Wayland as the default.

What’s coming soon, and we intend to contribute to, is the ability of splitting components, so that compositor and shell are in different parts and if the shell crashes it won’t bring down the whole desktop (and apps).

This temporary bug with Gufw which will not work on wayland will now be solved without using;

xhost +si:localuser:root

which also is a security risk. I agree with Will, out of the box users need stability and, may I add , some type of visibly working security interface, Gufw, which has been a staple for noobs and out of the boxers for some time.

I realize that libraries like WNCK may need some kind of privilege escalation or user prompt to work on Wayland which more correctly and thoroughly isolates clients, but eliminating all inter-client communication poses tremendous automation and accessibility problems. Ubuntu already lags badly behind other platforms (COM on Windows, ScriptingBridge on macOS) in terms of end-user automation, and eliminating even the ability to programmatically move windows around is another major step backward.