First, an apology. At the end of the last post introducing Xplain, I promised I’d have a new article out once a month. I had a lot of fun working on it, but Xplain has taken a backseat to real work. It’s on one of those “indefinite hiatuses” you hear about which are really just codenames for “eh, I should finish it, but I’ve got so much to do and staring quizzingly at the XKB protocol specification is not the best use of my spare time. I’m just going to let it die.” Yeah…
Sorry.
Ahem. “Real work?”
Wayland
For most of GNOME’s development, I’ve mainly been working on GNOME Shell and mutter, our desktop shell and window manager systems. I’ve always had somewhat of an interest in Wayland and graphics plumbing. So when we started to ramp up our Wayland efforts in GNOME, I jumped at the opportunity to work on it.
Over the course of the past nine months, I’ve been busy full-time on our Wayland support in GNOME. I haven’t spoken about Wayland much except in footnotes of Xplain and The Linux Graphics Stack. I’ve mostly tried to stay out of the political battles surrounding display server technologies and instead tried to focus on working hard building something awesome.
So that’s why I’m really excited about GNOME 3.12. We built something awesome.
For the first time, we now have an easily accessible Wayland session for testing. And now that I’ve broken my vow of silence, I’m going to try to blog a lot more about the progress we’ve made for Wayland in GNOME.
Sounds exciting! Now how do I test it‽
You want to try out Wayland? Awesome! Note, though, that it’s still very a preview, so lots of stuff won’t work. That said, lots of extensive testing is the only way we’re going to be on top of all the bugs and all the crashers. Your help testing and filing bugs will make GNOME on Wayland a success!
Wayland session support has been added to gdm. Once you have a distribution that ships GNOME 3.12, it should be fairly simple to try a Wayland session by simply selecting the new GNOME on Wayland option at the login screen.
It’s supposed to behave mostly like a regular GNOME session! If there’s any crashes, hangs, rendering artifacts, behavior differences, missing features, etc. you encouter, please, please file a bug. I personally look at every single piece of bugmail I get. Even if it seems obvious and dumb, file it. It takes us two seconds to mark a bug as a duplicate, so don’t feel bad about reporting too many bugs.
You might notice that the transition from gdm to Wayland isn’t perfect: the screen goes black, and there’s a blinking cursor for a few seconds when you log in. This is, at least for now, intentional. With the Linux APIs we’re given, at least as far as I’m aware, there isn’t a way to prevent this console showing up without also locking up your machine entirely if something goes wrong and nothing starts: the switch that controls whether the console should be shown is also the same switch that prevents the default VT switching keybindings from working.
For 3.14, we’ll be using logind to do session switching, so hopefully a lot of these issues we’re having with VTs will just go away.
But I tried Wayland during 3.10 and it crashed, burned my house down, and killed my pet Bengal tiger Leonard! And there’s no remote display support! Wayland sucks!
If GNOME 3.10′s Wayland preview was crashing for you beforehand, please give it another shot. I worked very hard making the Wayland port in GNOME 3.12 fairly stable, and I’ve used it for half a day without being able to make it crash. Obviously, I’m not perfect, so if your session goes down or does something funny, again, please file a bug and I promise I’ll take care of it.
Also, there is remote display support.
What we’ve done
There’s been a full six months of effort in between GNOME 3.10 and GNOME 3.12 in order to make it polished and complete. There really isn’t a major list of features I can point you to as a reason Wayland is better in 3.12. Here’s an incomplete list of things we’ve done, though:
We’ve been working on a more flexible, desktop-specific Wayland protocol, xdg-shell, built to replace the old wl_shell protocol. This new protocol provides atomic state change events, so that you don’t ever see a flicker when maximizing or full-screening a window. This protocol is still under heavy development, and we have plenty of ideas about how to make it better and more featureful than ever. We hope to have a first version of it stabilized for other application developers to port to midway through the GNOME 3.14 release cycle.
We’ve pushed ahead on GTK+’s Wayland backend to make it stronger than ever. It’s been surprisingly smooth: Wayland really is a fairly well-designed protocol that’s a good fit for a modern application toolkit.
Plenty of small bugs since 3.10 have been fixed: windows no longer flicker when they resize. Typing and input method support has gotten a lot stronger. Xwayland windows no longer hang or freeze when you drag them around. There’s no longer an “invisible box” around windows when you drag them around; they line up to the edges of the screen. Keybindings now work. Menus finally stay on top and don’t get occasionally stuck. Submenus are placed in the right spot. I could go on. It’s all the little things that account for 90% of the frustration and crashes.
Why Wayland matters
Our dedication towards Wayland has pushed us to build a cleaner architecture overall. What used to be a proliferation of X-specific video and input drivers is mostly culminating in centralized, standardized code. For input, we have libinput, which we’re using from Weston, mutter, and Xorg as well. What used to be a collection of chipset-specific video plugins for doing accelerated rendering have now been replaced by glamor, a credible chipset-independent acceleration architecture. What used to be large monolithic components heavily tied to Xorg and the Xorg input and video architectures have now been split out into separate, easily-reusable libraries with separate, easily-maintainable codebases. New, experimental features can be prototyped faster than ever before.
David Herrmann’s work on logind session support mentioned above was originally envisioned for Wayland, but it turned out to be such a great idea that my colleague Hans de Goede ran with the idea and integrated them into the X server, allowing us to run the X server without root privileges, a huge win for security.
Our work on GTK+ is also very much applicable to Win32, Quartz, and Broadway backends as well. A lot of the bugs that we’ve had to fix were bugs on other platforms. GTK+, somewhat unfortunately, was primarily developed as an X11 toolkit and that means our APIs often match up to X11, rather than a more modern system. When redesigning our APIs to support Wayland, we often find that X11 is the special case, and the new code is more portable and flexible than before.
The spoils of Wayland reach far and wide.
What we’re doing now
It can’t stop here.
For 3.14, we’re going to continue with Wayland development, and we’re all hoping to give a solid Wayland session that can be used for real work. No promises; six months is not a lot of time, and we have plenty to get done. Your testing will make it go faster, so if you get the opportunity, please start finding those bugs!
GTK+ is still missing lots of features in the Wayland backend. Most notably, we’re still lagging behind on drag-and-drop and clipboard support. Unfortunately, the APIs we currently provide to developers for these things are old and rusty and aren’t that great. A set of new APIs to make clipboard and drag-and-drop support more sane in GTK+ has been in the works since 2011, and Wayland is a great motivation to finish it off.
mutter’s codebase is almost 20 years at this point, and it’s somewhat surprising that it still has the same code structure as it did when Havoc Pennington started it as an X11 window manager. We’ve bolted additional features and functionality on: an X11 compositor here, a display server there, a Wayland protocol implementation sure why not, a nested testing mode, it goes on. I’ve already started hacking on a large-scale refactoring of mutter, “NWO”, that will restructure the entire program to help fix small nits in behavior and make it easier to add new features.
Right now, my current project and goal is that by the end of April, I’m hoping to ship mutter as a Wayland compositor without any X11 code running at all.
It’s pretty exciting stuff! I’m really looking forward to sharing more and more of our progress over the next few months. I’ll heading to San Fransisco in a few weeks for the West Coast Hackfest where I expect a lot of Wayland hacking will be done. Feel free to stop by if you’re in the area; we’d love to see you there!
As always, questions about our plans, or Wayland tech / Linux graphics tech in general are welcome. Feel free to leave a comment.
Also, excuse me while I get back to watching The Genius. You should go watch that too.