Jolla and Mer

As David Greaves held up a phone to begin his Embedded Linux Conference talk, he said that it would be no surprise that phone was not running Windows Mobile or iOS—the surprise is that it is not running Android either. In fact he was holding up the Qt/Wayland/systemd/Btrfs phone, which is better known as the Jolla phone. In reality, though, it is really a "Linux phone", he said, unlike Android-based phones.

Greaves started out at British Telecom, then worked on Maemo, and then its successor, MeeGo. The latter has been shut down, but Nokia and, especially, Intel did an awful lot of work in creating MeeGo. Two guys (he and Carsten Munk) looked at MeeGo and saw much that was useful there, so they founded the Mer project, he said. MeeGo was a bit over-ambitious, though, so Mer slimmed down MeeGo's 1500 packages to around 300.

That's the background for the Jolla (which Greaves pronounced as "Yah-La", which contrasts with our last attempt at capturing the pronunciation) phone. But he stressed that he was not giving a "pitch for Jolla", who he works for now. He is proud of what the team of 90 people has done in less than a year, in hardware design, and the development of an operating system and user interface, but the fact that Jolla has "proven" the Mer approach is also important.

One thing that Greaves's talk did not do was to dispel the murkiness around the boundaries and capabilities of the various components. Projects like Mer, Nemo Mobile, Sailfish OS, and the Jolla phone have been talked about over the years, but it is (and always has been) a bit unclear where one project stops and the next starts up. Part of that is likely caused by the overlap in participants among those projects, but it does, at times, get rather confusing.

In any case, Sailfish OS can (obviously) run on Jolla devices, but it can also run on the Galaxy S3 and the Nexus 4. That is part of the Sailfish for Android project. Support for more devices is in the works using the Hardware Adaption Development Kit (HADK or "haddock" following the nautical theme). The idea is that any device that is rootable and will run CyanogenMod will also be able to run Sailfish OS. That will allow many more folks to try out the phone operating system without buying any new hardware.

Technology

The user interface (UI) is important, Greaves said, and "a good place to start" looking at the technology used in Mer/Sailfish OS. The UI is based on Qt 5.2 and Qt Modeling Language (QML, the JavaScript-based UI language for Qt). Qt was chosen for a number of reasons: it performs well, is open source, is not Java-based, and it has a huge developer base. In addition, the existence of QML played a role in that decision because it allows rapid UI development, he said.

QtWayland replaces Android's SurfaceFlinger as the compositor for Sailfish OS. It is not currently using the Android HWcomposer (for 2D graphics) "strenuously", but there are plans to do more of that. The performance of QtWayland is "pretty damn good". Wayland was chosen because it is not difficult to work with and it meshes well with the Android shared-buffers approach, he said. In the end, the developers don't really notice Wayland at all, since QtWayland basically handles that interaction for them.

One area where Qt has problems is its size. It it is a "big piece of software", which means it eats up a fair amount of phone resources. But Qt 5.2 has started modularizing Qt, so that only certain parts need to be included.

Another technology used in Mer/Sailfish OS is systemd, which has "been quite polarizing" in the open-source world. There is something of a love it or hate it attitude about systemd, but they came down on the "love it" side, Greaves said. There were times where "we swore a little bit" at systemd, but by and large it served their needs well.

Systemd is "really fast", predictable, and well-documented, he said. The Journal is "a good fit for us" as well. There have been some issues with user sessions, but part of that may be that the version of systemd was adopted "a long time ago in systemd time". In fact, the biggest problem they have run into with systemd is its rapid development pace and how closely tied it is to newer kernel versions. He hopes that Debian adopting systemd will help alleviate some of those problems in the future.

For Sailfish OS, there is a mix of systemd and Android init code. In fact, the Android init is being run as a service under systemd. The uevent data from Android is being interpreted by udev rules and mount units are created from the Android rc files. Jolla is still exploring how to manage the "mix of two worlds", he said.

Mer/Sailfish OS uses Btrfs for storing data. No partitions are used; Btrfs's dynamic subvolumes are used instead. Snapshots are used to restore the factory settings, but those settings are old at this point, so Jolla is looking into updating that snapshot. In addition, it is looking at using snapshots for features like rolling back unwanted changes and for easy backups.

For handling the network, ConnMan is used. They ran into some problems using it, but writing ifup/ifdown scripts would have been far worse, he said. A recent upgrade to a newer version of ConnMan has helped, too. There are some difficult issues around network handling, no matter what solution is used. The rules for choosing when to use various data sources (3G, WiFi, etc.) and when to switch between them are rather complicated. For phone features, oFono was used, while PulseAudio handled the audio path; both worked quite well, with few problems, he said.

Libhybris

System-on-Chip (SoC) makers typically only create board support packages (BSPs) for Android. "Open hardware is great", Greaves said, but there is not much of it around. Instead there are a bunch of user-space blobs for various pieces such as the camera and haptic feedback. All of those blobs use the Bionic C library, but Sailfish OS (and many other Linux systems) use glibc. Hybris (or libhybris) is meant to bridge that gap.

The idea is to allow Bionic-using code to co-exist with glibc-using code in the same process address space. It required wrappers around Bionic functions and some name mangling (prepending "android_" on Bionic functions for example). It was done with relatively few patches (around ten) to Bionic, he said, mostly for functionality like POSIX threads, errno, hardware vs. software floating point, and so on.

Using libhybris means that, for example, the Android EGL and GLES libraries can be used by glibc applications. Then it is just a matter of "rinse and repeat" to get wrappers for other Android libraries, like Gralloc, NFC, OpenCL, Camera, and so on. Greaves said that the project(s) will be trying to make libhybris work for any device that has a CyanogenMod build.

The rest of the phone is a "fairly standard Linux stack". It uses Git for phone backups, though some tweaks were made to handle videos since "Git-committing videos is not a bright idea". It uses RPM as its package manager, and Gstreamer for multimedia content. It uses the Linux kernel, too, of course, though the project doesn't do much with it: "if it boots and runs the hardware", it gets left alone.

If you build it ...

The Mer project has a Platform SDK that is used to build it. Mer "didn't want to have to worry" about which tool versions were installed on the builder's system, so it includes all of the right versions to be used inside of a chroot(). It uses Scratchbox2 for cross-compilation support. Scratchbox2 is "sane, sensible, and usable", Greaves said, which is quite a departure from the earlier Scratchbox. It is so much different (and better) that he wishes it had been given a new name.

Packages can be created easily. Typically it requires some minor tweaks to an existing package spec file. The result of the build is an RPM file that can be installed on the device. There is some LD_PRELOAD trickery in Scratchbox2 to invoke the cross-compiler (using Lua to do pattern-matching), all of which is "a little ugly", but makes it "seamless to the developer", he said.

The SDK can run in a virtual machine, which allows Windows and Mac users to use it. There are a small number of people in the company and project, so porting all of the tools to multiple platforms is not a viable solution. Virtualization solves that problem, he said.

Jolla and Mer use the Open Build Service (OBS), which is an "incredibly powerful build system", he said. Mer focuses on trying to enable vendors to make products, and OBS fits right into that model. Someone can submit a package to OBS and it will automatically build versions for multiple architectures.

It is not just packages that are built that way, though. The latest development tree of Mer and Sailfish OS are built regularly, typically driven by Git commits. The automated system will invoke mic (originally, the Moblin Image Creator—and the reason Mer had to start with an "M", he said with a chuckle) to create an image that can be flashed onto a device for testing.

Working in the open

Mer and Jolla came out of Maemo and MeeGo, which taught them a lot about working in the open. In the MeeGo days, some of the now-Jolla folks sometimes gave Nokia and Intel a hard time about not working more in the open. But now, those folks appreciate the problem from the other side. It's a hard problem and they are trying to learn from the mistakes that have been made in the past.

For Jolla, there are (at least) two pieces to the problem: working with its upstream (Mer) and collaborating with other vendors on new devices. Jolla's internal policies are geared toward the way it works, some of which may or may not mesh well with open-source projects and Mer in particular. For example, all commits must refer to or close a bug number (as the bug tracker is also used as a task tracker). There is an automated process that adds the commit message to the bug tracker, but that isn't particularly useful for Mer, which has a public bugzilla.

Jolla has an internal open-source policy as well. To start with, employees should participate in open-source projects as themselves, rather than as representatives of Jolla. But not all employees came from an open-source background, so some amount of education is needed. Policies covering interactions with projects is part of that as well. Helping to create those policies sometimes made Greaves feel like Bill & Ted: "Be excellent to each other", he said with a laugh.

The Mer project consolidates all of the open-source work that Jolla does (much of the UI layer is still closed). The Mer project's vision is "to make it easy to make devices". That explains what the project is doing and why, he said. For example, there is no UI for Mer. Nemo Mobile was a project started to create the middleware and UI for Mer, but most who are using Mer also use the middleware, so the middleware has been moved into Mer. That means that Nemo Mobile is just UI now, which shrinks it down considerably and, he hopes, makes it more accessible as a community project.

From the Mer project's point of view, the Jolla device is "huge credibility shot" for the project. But Mer works with others too, including Ubuntu and Intel on libhybris. Mer aspires to be more than just code, because "code is not enough". For devices to be easier to make, it requires best-practices documentation in lots of areas: quality assurance, how to do releases, how to manage regressions, building images, handling source repositories, bug tracking, and more.

But, the Jolla phone has shown that the Mer approach works. It took around nine months for 90 people to deliver a working phone with a brand new UI. Others can do the same.

All of the projects would love to have more participants, he said. For example, the camera does not currently work on Sailfish for Android on the Galaxy S3, but Ubuntu got the camera working for Ubuntu Touch, so "come help make it work". In addition, phone platforms are really just 3G data platforms with a touchscreen and some other interesting hardware; phones are not the only things that can be created on such a platform.

While Mer-based devices may not be free-software compliant (because of the binary blobs), Mer will be ready when free drivers come along. It doesn't make sense to wait for those drivers and then to start working on phones and other devices, he said. In that scenario, devices that are free-software-only will have fallen way too far behind.