A journey through the Galaxy: leveraging Wayland to build custom Shells


In our last post I gave an overview of the status of Ispirata and where we’re headed. So much for that, let’s get to the meat and talk about some technical innovations we’re introducing with the upcoming new Hemera. Today, I’d like to give you a very quick rundown of our new architecture, and the new possibilities it opens up for developers and integrators.

Some of you might remember when we talked about Gravity in the past. Gravity is our middleware and the very core of Hemera, which makes everything work. Nowadays, Hemera’s structure looks (pretty much) like this:

How Gravity works

How Gravity works

We’ve worked further into our galaxy-inspired naming, and matched it to our new design. Let’s try to make sense out of this scheme though. First of all, what were we trying to accomplish?

  • Sandbox to the highest possible extent running applications. Although this is something we already had.
  • Make the Sandbox design less restrictive as possible, allowing apps to do complex things while retaining safety.
  • Improve performances and minimize resource usage
  • Allow multitasking
  • Allow corner-cases (multiple independent displays)

The design we came up with is the one you see above. Let’s dive into specific components.

  • Gravity Center is the main player, the only component of Hemera running as root, and the master of the Device. It starts up as soon as possible, and orchestrates the execution of applications and any other Hemera components. It leverages the amazing systemd for that, which is used all around Hemera as our session handler and application launcher.
  • Star sequences are runtime components of Gravity Center which open a private communication channel with each Star.
  • A Star is a container for an Hemera session. Stars are persistent logical areas of the device in which applications are launched and managed. Usually, each display has its own Star, and a Star can be created for the Headless context (if any). Stars are our first sandboxing level: we’re already in an unprivileged environment. After all, it is indeed quite difficult to escape the gravity of a star (yes, the whole naming scheme is designed to make sense other than being cool).
  • Parsec is the manager of a Star. It is the only component in a Star allowed to interact with its Star Sequence, and orchestrates everything which happens in the Star, with help from Gravity Center and its Star Sequence when needed. Applications interact with Parsec only – Gravity Center is completely obscured from them.
  • Orbits (some of you might recall) are our containers for applications. Now they have been moved in the context of a Star, and to ease the most common use case, you no longer need to create a custom Orbit – each application is now capable of declaring and creating its own Orbit autonomously, hiding this detail to the final developer.
  • Orbits are sandboxed into their own Unix session, with a twist. The unix session serves as a mere container for the application(s) in the Orbit, whereas other services (pulseaudio, etc…) are shared with the Star. There’s a bit of trickery which allows us to do that – we had to twist fd.o paradigms in our direction, and create a “Star bus”, which allows for IPC between the Star’s applications, Parsec, and other services, handling DBus activation in the correct user and context.

 

This description pretty much fits the Star on the left of our previous scheme. It is how Gravity and Hemera used to work: we improved in every regard our design and structure. A Star can hold one active Orbit, which can be changed at runtime, and allows for super-fast and easy development of single appliance devices.

There’s a new thing though: Planets. A planet is a very special kind of Orbit, which has some superpowers. Namely, launching and managing other applications, which are launched as Satellites. Each Star can have only one active orbit at a time, but with Planets this changes radically.

Confused? Let’s try to put this in a Mobile perspective. When you launch your phone, the system boots and prepares a display context. This is the equivalent of our Star Sequence. Once booting is done, you’re in your home screen. This is your Planet. From there, you can launch your apps. These are your Satellites.

With this in mind, a Planet allows you to create your own launcher/shell/home screen, with a set of APIs for managing applications. We go slightly further than the mobile use case of course: you can also implement a Desktop-like shell, with window decorations and real multi-tasking. We will dedicate, in March, a blog post series on Planets and what you can do with them in detail.

There is a catch: we have a hard dependency on Wayland for this. Wayland is a new and trending replacement for X, depending on OpenGL(ES), and perfectly fit for our use case. Again, we will dedicate more space on this blog (even though I won’t be writing it, I’m definitely not the resident Wayland expert in house) on our usage of Wayland.

In our design, Planets are Wayland compositors, and are capable of using Hemera’s APIs to launch and manage applications’ lifecycles, and Wayland to manipulate their windows. On the other hand, and in full Hemera fashion, each Star has its own system compositor, which takes care of directly interacting with the hardware and the framebuffer: we chose Weston for that. The reason behind this is the impressive amount of work which is going into Weston, and the fact that it is turning in a direction we really like: a solid foundation for desktop environments. This perfectly fits into our design, where our Star will use Weston as its system compositor, and our Planet (compositor) will run on top of Weston and take the main stage.

Though, you might wonder: how safe is it to hard depend on Wayland in a world where only a very limited amount of SoC has Wayland support? First of all, “standard” Hemera does not require Wayland: we’re still giving multi-platform choice, among which X11 or direct EGL. One thing I’d like to address is that we will not support (at least towards our customers) wayland-shm, which means you need a GLES2 GPU to leverage our Wayland stack, so keeping an option for those devices with no graphics stack was vital – we care a lot about them. So this does not mean you will need Wayland to run Hemera, but you will need Wayland to run Planets.

And we indeed have a solution for those devices with sufficient GLES support and no Wayland stack. But I don’t want to spoil too much: we’re currently finalizing our tests and integrations, and we will have news and demos very soon.

 

Good news is: in March, we will be releasing a Beta version of Hemera Planets, you will be able to test and use on the Raspberry Pi, a rather nice and comfy native Wayland environment. And if you happen to be around Italy, you can see it in action at Qt Day Italy 2015, where I will have a talk explaining and showcasing all of this. And of course, look for us at Embedded World 2015, you might indeed snatch a preview there as well, who knows!