Benjamin Berg

If you are already using GNOME 3.34, then most likely your session is managed using systemd right now. For a long time now we were already running a systemd instance for every user, which is used to launch DBus and for DBus activated applications. So, with GNOME 3.34, we finally took the next step and moved the rest of the session over to run using systemd.

From a user’s perspective nothing should have changed and at this point I believe that most regressions have been dealt with. Neither will this change affect application developers for the time being as XDG autostart files continue to be supported and are prefered at least for the time being.

The great thing is, that this enables further improvements. There has been a lot of work to allow Xwayland to be started on demand and systemd plays a small part in that feature. Similar, we will also be able to shut down services that are only needed if specific hardware is present (e.g. smartcards). Also, using systemd it is now easy to sandbox all components which will give you an extra bit of security.

That said, there are a few changes, concepts and general information that is worth mentioning.

Slices, scopes and user sessions

On a systemd managed system each user is assigned a user-X.slice (systemd.slice(5)) and the user’s session will be run in a session-Y.scope (systemd.scope(5)). You can also see a few other user specific units on the host, including user@X.service, which is the user’s systemd instance. This is a separate systemd process for the user and it will shut down again if the user is not logged in anymore.

With the systemd move, not only DBus activated applications and services, but rather your entire session is now launched using your user’s systemd instance. This has a few side effects that may seem odd at first. For example, the previously mentioned session-Y.scope which used to contain over 200 processes is now down to a mere 4 processes. Another side effect is that it got harder to understand which session a process belongs to (this is relevant for a number of services) or that ps will not show a tty anymore.

But, we have addressed these side effects and hopefully there are no regressions at this point. Your GNOME session is still invariably bound to the session-Y.scope (e.g. using loginctl kill-session continues to work reliably). And services have been updated to understand the new regime and pick the correct session in all cases. To handle all this, new API was also added to the systemd DBus interface and further improvements may happen in this area.

Trying it out

So, if you have GNOME 3.34, you can now apply all the neat tools that systemd has manage your user’s session. Just remember to add the --user option, and things should work as expected. A good candidate for trying all this out is gsd-media-keys.

If we look at systemctl --user, we’ll find two entries:

• gsd-media-keys.target
• gsd-media-keys.service

Note that failed units will not show up in the list, so it is advisable to always check the log if you suspect a service failure. Unfortunately this is needed so that you can reliably log in again after a session failure.

We can control gsd-media-keys.target (not gsd-media-keys.service), so you can try stopping and starting it and you will notice that most global keybindings will stop and start working.

• systemctl --user stop gsd-media-keys.target
• systemctl --user start gsd-media-keys.target

We can also pull up the log messages for the service from journalctl.

• journalctl --user -u gsd-media-keys.service

But, unfortunately, it will not log much information by default. But, knowing systemd and GLib environment variables we can run:

• systemctl --user --runtime edit gsd-media-keys.service

and write:

• [Service]
Environment=G_MESSAGES_DEBUG=all

This enables debug messages when the service is restarted next. The configuration will not persist as we passed --runtime. If you now restart gsd-media-keys.target and inspect its log again, you will notice that it contains a lot more information.

Developing GNOME

If you have a development version of GNOME installed somewhere outside of your normal path (e.g. jhbuild) and use this to log in, then you may need to update your setup. In jhbuild there is an example jhbuild-session script that ensures that the correct unit files will be used. The relevant lines copy them into the user’s $XDG_RUNTIME_DIRECTORY and reload the systemd daemon.

On a final note, I would like to thank everyone who has worked on this in the past. As far as I know, the first experimentations were done by Canonical, in particular Iain Lane did a lot of work and submitted the first patches. I picked up this work and made plenty of improvements to get it over the finishing line.

If you don’t have GNOME 3.34 yet, then try it out by installing Fedora 31 beta or your favourite distribution that includes GNOME 3.34 already.

On GNOME we usually had no good way of using remote display devices like Chromecast, Miracast or AirPlay. VLC for example does support streaming to Chromecast, but the Miracast implementations were all not integrated well enough to be usable. Also, at least Miracast requires the use of the H264 or H265 codecs, which have been problematic due to licensing requirements.

I have been working on a gnome‑screencast application, which currently has working support for Miracast devices. It requires a current development version of NetworkManager, but should work out of the box otherwise. If you are on Fedora, you can try out gnome‑screencast by using my copr repository.

To stream to a Miracast (revision 1) device, a few things need to happen. First we need to establish a Wi‑Fi Direct connection. We also need to start an RTSP server that the sink can connect to. And finally, once the sink is connected, a GStreamer pipeline is used to fetch the screen content from mutter, encode it and send it to the Miracast sink.

For the encoding, gnome-screencast will make use of the OpenH264 and Frauenhofer FDK ACC codecs that are available on Fedora. If you have better encoders installed, then these may be used automatically.

When available, gnome‑screencast will make use of the Mutter Screencasting API which allows it to grab the screens content on Wayland. The API is still improving in mutter, and in the future it will be possible to add support to stream the cursor separately.

One major piece that was missing for Miracast devices is integrated support for Wi‑Fi Direct (a.k.a. Wi‑Fi P2P) in our platform. While this was supported in the lower parts of the stack (Kernel and wpa_supplicant), we were lacking the required bits in NetworkManager to enable the usage in GNOME. I worked on adding the required support and thanks to Thomas Haller this has now been merged into NetworkManager 1.16.

With all this in place, it is possible to implement proper support for screen-casting using Miracast in GNOME. The below video shows gnome-screencast in action streaming my laptop screen with the Blender short film “Caminandes 3: Llamigos“ playing.

If you have a Miracast compatible device, then please try out the copr repository. You can report issues on github. Also, feel free to comment here or write me a mail with your experiences.

A while ago we opened the Red Hat office in Munich to girls and boys aged 12-16 from schools in the region. This was part of the Girls’ Day and Boys’ Day initiatives backed by a lot of organisations including the German government. The goal is to introduce the girls and boys to careers that are dominated by the opposite gender which has been shown to considerably decrease the gender afinitiy in girls when asked about their favourite career choices.
We also had the chance to participate in Boys’ Day as the Munich office mainly houses non-engineering parts of the company including human resources and marketing.

The day started with Emilie giving a summary about Red Hat as a company and what open source is and means. After that, we split the groups and the boys worked together with the marketing team for the rest of the day. With the girls we spent the day connecting a few LEDs and a button to an arduino like microcontroller and creating basic programs on it. We deliberatly kept the tasks quite simple, focusing on showing the direct link between the program and result. During the time the girls incrementally learned to program the LEDs and finally build a simple traffic light application which turns the light to green when the button is pushed.

At the end of the day we gave the full set of electronics to each of the girls. This includes the NodeMCU, breadboard, LEDs and push button. We also included the flash drive with the customised Fedora live image containing the development environment.

Many thanks goes to Miriam, Oliver and Jens who did much of the preparation work, from registering us as an organisation, building the live image to working out the tasks for the day and getting the hardware. Christian Kellner and Helene also helped before and on the day allowing us to host up to 15 girls.

This was the first year that we participated, and the feedback has been positive. We believe it worked out well and would like to participate again next year.

GUADEC is approaching quickly and we just spend a whole day finalizing the planning so that everything will go smoothly during the conference. A few announcements for the conference are still in the pipeline including the social events and the complete talk schedule. So watch out for more announcements during the next two weeks.

Registration will remain open, however if you are not registered yet, then please do so now to speed up handling for everyone on the day. If you are arriving early for the core days then you can also still sign up for one of our workshops.

I am looking forward to seeing you here in Karlsruhe!