Category: Software

Initial Plasma Mobile enablement on Librem 5 i.MX 6 test boards

As many of you know, the Librem 5 phone will work with two options for your desktop environment, a GNOME based phone shell and Plasma Mobile. Working closely with the KDE community, we were able to install, run, and even see mobile network provider service on Plasma Mobile! The purpose of this article is to show the progress that has been made with Plasma Mobile on the current Librem 5 development board. Here, the setup steps and overcome challenges are highlighted.

The Setup

The i.MX 6 board started off running PureOS (which, as you may know, is based on Debian testing) with a running Weston environment. Several KDE and Qt packages were needed for the Plasma Mobile environment and a few packages were not available within PureOS so needed to be built: plasma-phone-components, kpeople-vcard, and plasma-settings. For a complete list of technical steps on how Plasma Mobile was setup on the dev board, see

Once all of the necessary pieces were in place, running Plasma Mobile was as simple as a single command:

$ kwin_wayland --drm plasma-phone

Overcome Challenge #1: The Evil Display Issue

That is when we discovered that the desktop just wasn’t rendering properly. The prototype phone screen looked like an old TV in-between channels. Also sometimes a KDE wallet pop-up window would appear as well (seen in the picture below).

So troubleshooting hats were donned and gdb dusted off. It was discovered that if the export QT_QPA_PLATFORM=wayland line is commented out of the plasma-phone script, then our display issue went away! But the QT_QPA_PLATFORM variable is needed to set the platform to be Wayland. So then the question became, “why is the graphics driver, etnaviv, not working in Wayland mode?”

It turns out that the missing piece was that the zwp_linux_dmabuf protocol was not yet supported in Plasma. For more information on why zwp_linux_dmabuf is needed for Etnaviv driver, check out this announcement.

There already was an upstream bug report tracking the issue, with patches to kwin and kwayland. Thanks to Fredrik Höglund for his work done on zwp_linux_dmabuf.

We incorporated upstream’s patches into our development build of kwin and kwayland and voilà! We were now able to export the QT_QPA_PLATFORM variable and see a beautiful Plasma display!

Overcome Challenge #2: The Invisible Mouse

It was obvious that the keyboard worked, because it was possible to type the password to log back in from the blue lock screen. The mouse, however, seemed to be nowhere in sight. However, by moving the mouse around (assuming it’s there and just not visible) and clicking, we saw that it was possible to open applications but only by accidentally clicking the right thing.

The issue here is that if the DRM driver doesn’t provide the cursor plane. There is an outstanding bug report on this issue.

In the meantime however, we can work around this by holding Ctrl+Super keys to draw a rotating circle around the mouse cursor position, as you can see in the video below:

This is good enough for our current needs, since ultimately we will receive the missing touch adapter hardware for the dev screen and we would no longer need to use of a traditional mouse pointer.

Overcome Challenge #3: Mobile Network Provider Service

Naturally, the next challenge we attempted was to make a phone call. First, the SIM card needs to be recognized, and the provider information retrieved from the modem. This required additional packages, some of which needed to be built from source. To actually get the Sierra Wireless MC7455 to recognize the SIM card, a PIN needed to be sent, modem brought online, and antennas attached. Then, when Plasma Mobile started, we were able to see the mobile network provider signal strength in the top left corner!

Due to the modem we currently have installed on our i.MX 6 board, phone calls are not supported so we could not fully test that part yet. But don’t worry, the Librem 5 will have a modem capable of actually placing phone calls 😉

One step closer and 9,000 kilometers across

Together with the community, Purism is making progress on the road to supporting Plasma Mobile on the Librem 5. There is still more effort needed and this collaboration with the Plasma community will be working towards the successful deployment of Plasma Mobile on the Librem 5.

From 27th of February to 1st of March, Todd and Nicole visited the Embedded World electronics supplier trade show in Nürnberg (Germany) to meet with potential parts suppliers, especially with representatives from NXP and distributor EBV Elektronik. Furthermore, we had productive meetings with suppliers for WiFi, BlueTooth, and sensors, and also talked to a number of board makers and designers.

This visit and the talks prepared us well for our next trip, this time to Shenzhen, the silicon delta of China. We have made appointments with a number of suppliers that are interested in cooperating with us on the Librem 5 phone project as well as on other hardware projects. We will have an extensive two week meeting marathon in order to narrow down the choice and pinpoint the best suppliers for our project.

Librem 5 puzzle pieces starting to come together—graphics, adaptive applications, docs and SDK

The Librem 5 is a big project. And like a lot of big projects, as you probably know, it can appear overwhelming, until you can break the parts down into logical steps. Like a large puzzle scattered on a table, our team has been organizing and beginning to assemble all the pieces. This is very exciting to progress through the initial daunting scope, accepting the tasks, start working and then… after some time, solutions emerge and almost magically align.

In our previous blog posts we described what we were starting to work on, and these efforts began to prove themselves out significantly during our week-long hackfest where part of our software phone team gathered last week in Siegen, Germany. Read more

GNOME and KDE in PureOS: diversity across devices

PureOS, a Free Software Foundation endorsed GNU distribution, is what Purism pre-installs on all Librem laptops (in addition to it being freely available for the public to run on their own compatible hardware or virtual machines). It comes with a GNOME desktop environment by default, and of course, since we love free ethical software, users can use KDE that is also available within PureOS. This is the future we will continue to advance across all our devices: a PureOS GNOME-first strategy, with other Desktop Environments (DEs), such as KDE, available and supported by Purism.

At Purism we want a unified default desktop environment, and considering that we have chosen GNOME to be the default on laptops, we hope to extend GNOME to also be the default on phones. The ability for users to switch is also very powerful, and having a strong, usable, and supported alternative—that is, KDE/Plasma—for the Librem 5 offers the best of the “unified default” world and the “usable user choice” worlds.

Symbiotic GNOME and KDE partnerships

Purism has partnered with both GNOME and KDE for the Librem 5; what this means simply is that users running PureOS on their Librem 5 will get the choice of a GNOME environment or a KDE/Plasma environment, and the user could always switch between the two, like what is already the case on computers running PureOS. Will there be other partnerships in the future? We imagine so, since we will be happy to support any and all ethical OSes, GNU distributions, and want to make sure that the future is bright for a non-Android-non-iOS world.

While the initial GNOME and KDE partnerships mean uplifting diversity at the top level (and greater choice for users), each have a slightly different developmental and support roadmap. The reason for this is pragmatic, since KDE is very far along with their “Plasma” mobile desktop environment, while GNOME is farther behind currently. Investing time and efforts to advance the status of mobile GNOME/GTK+, aligns with our longer-term goals of a unified default desktop environment for PureOS, offering a convenient default for users. Diversity is why we are supporting and developing both GNOME/GTK+ and KDE/Plasma.


  • KDE: Purism is investing in hardware design, development kits, and supporting the KDE/Plasma community, and will be sharing all early documentation, hardware designs, and kernel development progress with the core KDE/Plasma developers and community.
  • GNOME: Purism is investing the same in hardware design, development kits, and supporting the GNOME/GTK+ community as we are with the KDE/Plasma community. In addition, Purism is needing to lead some of the development within the GNOME community, since there is not a large community around an upstream-first GNOME/GTK+ for mobile yet.

Choice is good, redundancy is good, but those are ideal when there is minimal additional investment required to accomplish technological parity. Since Purism uses GNOME as the default desktop environment within PureOS on our laptops, we figured we are going to invest some direct development efforts in GNOME/GTK+ for mobile to stay consistent across our default platforms. Adding KDE as a second desktop environment is directly aligned with our beliefs, and we are very excited to support KDE/Plasma on our Librem 5 phone as well as within PureOS for all our hardware. We will support additional efforts, if they align with our strict beliefs.

Why not just use KDE/Plasma and call it a day?

If we were doing short-term planning it would be easy to “just use Plasma” for the Librem 5, but that would undermine our long-term vision of having a consistent look/feel across all our devices, where GNOME/GTK+ is already the default and what we’ve invested in. Supporting both communities, while advancing GNOME/GTK+ on mobile to allow it to catch up, aligns perfectly with our short-term goals (offering Plasma on our Librem 5 hardware for early adopters who prefer this option), while meeting our long-term vision (offering a unified GNOME stack as our primary technological stack across all our hardware). It is also a good way to give back to a project that needs our help.

Why not just push GNOME and GTK+ and forward?

Because having an amazingly built Plasma offering available early to test and ship to users is a superb plan in many ways—not just for redundancy, but also because KDE/Plasma also aligns so well with our beliefs. The product readiness across these two desktop environments are so different it is not easy to compare side-by-side.

Empowering both communities is possible

Overall, Purism is investing the same amount across hardware, boot loader, kernel, drivers and UI/UX. These are shared resources. The deviation boils down to:

  • GTK+ and the GNOME “shell” development, that Purism is planning to be directly invested in, in close collaboration with upstream
  • Community support: by being involved in both communities, we are effectively doubling our efforts on supporting those communities, but that is a small cost for the greater benefit of users.

Supporting both KDE/Plasma and GNOME means we will continue to build, support, and release software that works well for users across Purism hardware and within PureOS. Purism fully acknowledges that each platform is in different release states, and will be working with each community in the areas required—be that software development, hardware development kits donated, community outreach, conference sponsorship, speaking engagements, and offering product for key personnel.

PureOS now features AppArmor activated by default

Purism, the Social Purpose Corporation focused on software freedom, privacy and security, proves it is dedicated to making its products secure straight off of the factory floor. Now, new PureOS installations (including those provided with Librem devices) have AppArmor activated by default. Let us first look at what AppArmor is, and then why we chose it specifically to strengthen PureOS. Read more

Running Plasma Mobile on an i.MX 6 test board

On the road to a working mobile phone, doing some initial evaluation and testing of the current state of existing user interfaces and frameworks is key, to evaluate what can readily serve as building blocks and what needs work. Last weekend I did an initial experiment in getting Plasma Mobile working on our i.MX 6 based test development board, using a 4.13.5 Linux kernel and stock Debian Testing. Initially, I encountered a few problems with KWin not wanting to start a Wayland compositor due to not recognizing the device as OpenGL ES 2.0 capable and also not finding a few needed OpenGL extensions. After some digging and with help from Plasma Mobile developer Bhushan Shah we tracked this issue down to a bug in libepoxy that was solved a long time ago. Unfortunately, Debian’s packaged version of this library was very old, so I upgraded it to a newer version manually (and we will get it updated in Debian soon). This resulted in a working Plasma Shell on the device.

The next step was compiling and installing the Plasma Mobile components from current Git master repository and running the mobile shell. This initially led to graphical glitches in the display, which were caused by KWin running as root (which you should never do as a user, but I did not think this would also cause major issues just for testing whether the shell works or not). After switching to a regular user for running the KWin wayland compositor and removing a dead call to upstart from the plasma-phone launch script, I could start the Plasma Mobile/Phone shell with the kwin_wayland --drm --xwayland plasma-phone command.

Here are the screenshots you have probably been waiting for the whole time:

Plasma Mobile on i.MX 6 main view
Plasma Mobile on i.mx6 running the Discover application center
Plasma Mobile on i.mx6 App drawer

Of course this is not a final product, by any stretch of the imagination. It’s simply a test to see that it runs. There is a lot to do in terms of performance improvements, as Plasma Mobile still runs pretty slow on this kind of hardware (which could be less of a problem in case we use the i.MX 8 platform). Also, these initial tests were done using recent—but not the most up to date—versions of Plasma, KDE Framework and Qt (KWin/Plasma 5.10.5, KF 5.37.0, Qt 5.9.1), while a lot of performance improvements and bug fixes went into the latest versions. So it is definitely worth switching as soon as possible to tracking KDE’s latest development releases to benefit early from improvements done in the whole stack.

In general, Plasma Mobile already provides a usable (albeit alpha-quality) mobile interface today. The Qt Quick/QML based Kirigami component library and interface guidelines also provide a nice framework for mobile application developers, that have been tested on Android as well, and works nicely on and with the Plasma Mobile shell.

We are looking forward to seeing what we can do with the Plasma Mobile shell in future. Many thanks to Bhushan and the KDE community for helping with some issues encountered when making Plasma work on the i.MX 6, and their plans on making a real Plasma Mobile alpha release soon. If you are interested in the Plasma Mobile roadmap, this recent post from Sebastian Kügler might be interesting for you.

Initial Touch and Web Browsing experiments on Librem 5 prototyping boards

When it comes to prototyping the Librem 5, we are working hard and making progress on several sides. As you have seen in yesterday’s testing update blog post, we are working on development hardware in order to start getting software development groundwork done. Today, I’m sharing the results of a quick experiment with web and touch on a prototype board. Read more

A new boot splash for PureOS

A quick update about PureOS… from the design team this time! 😉

For the new version of PureOS (codenamed “Prometheus”), I am working with the developers to make a very smooth and pleasant user experience when installing and launching the system. We want to make sure that PureOS is not only secure, but also a beautiful and enjoyable experience, designed for everyone. No exceptions!

So, I am currently working hard on polishing the visuals. The video below shows an example of the animation that will now take place at boot time in PureOS.

Every new Librem ordered with PureOS pre-installed should ship with this beautiful PureOS update in the coming weeks (we’re working hard to make the PureOS release on time for factory installs!) If you already are using PureOS, a software update will also arrive soon for you.

If you like it so much that you can’t wait for it to be released with PureOS, or if you want to customize its look to make it yours, you can download the source files here.

Your own music studio with JACK, Ardour and Yoshimi

Last week, after flashing coreboot on my Librem 13 (as a beta tester of the new coreboot install script), I came across a few problems with my heavily tweaked PureOS install, so I decided I would do a full, fresh install of PureOS 3.0 beta so my environment would be much closer to what a new user would expect.

While re-installing all my creative environment, I decided that I would do a quick tutorial on installing and using Jack as it is not straight forward and that there are not so many tutorials about it on the Internet.

What is JACK?

JACK stands for “JACK Audio Connection Kit”. It is a free software that lets you handle audio input and output between different applications.

You can see it as a set of audio jacks that you will be able to plug between different programs.

For example, you can use it to connect a software synthezizer (Yoshimi, ZynAddSubFX) to a multitrack sequencer (Ardour, LMMS).
You can use it to connect an audio editing software (Audacity) to a video editing software (Blender).

Many applications have Jack support. Here is a list from the JACK’s website.

As an example for this tutorial, I will show you how to use Yoshimi with Ardour.

Install the applications

First of all, we need to install all the required applications

sudo apt install qjackctl ardour yoshimi

Enable real time scheduling

Real time scheduling is a feature of all Linux based operating systems that enables an application to meet timing deadlines more reliably. It is also considered to be a potential source of system lock up if your hardware resources are not sufficient so, most of the time, it is not enabled by default.

As mentioned on the JACK’s website, JACK requires real time scheduling privileges for reliable, dropout-free operation.

There is a well detailed tutorial from the JACK’s team that describes how to enable real time scheduling on your system. I will go through the main steps here. It works for me on PureOS but should also work without problem on many other GNU/Linux distributions.

First of all, create a group called “realtime” and add your user to this group (replace USERNAME with your current login) :

sudo groupadd realtime
sudo usermod -a -G realtime USERNAME

You can check that “realtime” is now part of the user’s groups by running the following command :


Also, make sure that the user is part of the audio group. If not, just add it :

sudo usermod -a -G audio USERNAME

On PureOS (and Debian), you should have a folder called /etc/security/limits.d. If so, just create and edit the file /etc/security/limits.d/99-realtime.conf with your favorite editor. (If you don’t see this folder, you need to edit /etc/security/limits.conf).

sudo vi /etc/security/limits.d/99-realtime.conf

Add the following lines and save the file :

@realtime   -  rtprio     99
@realtime   -  memlock    unlimited

You need to logout and login again for the changes to take effect.

WARNING : You should only add new or existing users to the “realtime” group only if an application that they use (like JACK) requires it . By doing so, you give them pretty high privileges to interact with the process priorities, and this may affect the whole usability of the computer.


Before being able to connect anything with JACK, we need to set it up and start its deamon. For that matter, we will use QJackCtl which is a graphical application that controls JACK’s inputs and ouputs.

We will first make sure that JACK is setup correctly. Press the “Setup…” button.

I am not an expert with audio hardware and configurations and this setup is working perfectly on my Librem :

  • Driver: alsa
  • Realtime : yes
  • Interface : hw:PCH
  • Sample Rate : 44100
  • Frames/Period : 128
  • Periods/Buffer : 2



Save your settings and, on the main QJackCtl controls window, press the “Start” button. After a few seconds, you should see the “Connections” window popping up. This is where all the connections take place.

Connect Yoshimi to Ardour

Now, we are ready to connect our virtual jacks. It is time to open Ardour and create a new session. You should now see a lot more connections in the JACK’s connections window. It shows how Ardour interacts with the system’s audio inputs and outputs.

Let’s add a new track to Ardour. Click the menu “Track”->”Add Track, Bus or VCA…”. Call your new track “Drums” and set it as stereo.

Now you see 2 more Ardour inputs in the JACK’s connections window. They show the name of the audio track that we just created and they are currently connected to the default system’s capture device (the microphone). That is is not what we want so we will disconnect them.

Right click on one of them (Drums/audio_in 1) and chose “Disconnect”. It will disconnect the audio capture device. We will now connect our track to Yoshimi.

Open Yoshimi and wait for it to be fully loaded. You should now see the Yoshimi’s output appear on the JACK’s connections window. In order to connect the Yoshimi’s output to the Ardour’s input, just drag one on top of the other (make sure to respect the vertical order).


You are now ready to enjoy your fully operational free software powered professional music studio! 🙂

Please, feel free to comment this post or ask any question in our forums.

Have fun! 😉

Releasing the beta of PureOS 3

After our alpha release in November, we are today releasing the beta for PureOS 3.0, which we intend to release as a final release in time for our upcoming new laptop batch shipment (more news on that soon).

As PureOS uses a rolling release model, software all across the stack continued to receive updates since our first alpha some months ago, even though the core of our work has been to improve and deploy new infrastructure to support efficient development of this operating system and to make the PureOS experience more pleasant for users, too. The PureOS infrastructure is now better at exposing migration/update issues, which means that we iron out broken or missing package dependencies more quickly (with the goal of preventing them from ever being encountered by users, although such occurrences are already rare). Building this infrastructure for PureOS is some very ambitious—and often invisible—work that we are accomplishing as the foundation for all PureOS development.

We are also in the final stages of preparing proper developer documentation, closely modeled on Debian’s contributors documentation and procedures, but pointing to the right bits and pieces when it comes to PureOS.

FSF endorsement is work in progress: we are working with the FSF and addressing any concerns or requests they may have. As per the FSF’s requests:

  • The new PureOS website is now fully separate and works with LibreJS.
  • Iceweasel/Firefox was removed from the archive (its presence there was actually due to a repository synchronization bug) and we modified the add-ons system to avoid the possibility of installing non-free add-ons by mistake. That said, this is one of the reasons why PureBrowser exists, and PureBrowser will continue to be the default. The forced removal of Firefox/Iceweasel caused some trouble with the PureOS package repositories archive but this will be fixed before the final release.
  • TorBrowser is now torbrowser-launcher, a package that downloads and installs the official Tor browser with updates being applied as soon as the Tor project publishes them.

On the security front:

  • A Wayland-based GNOME 3 experience remains what we ship by default.
  • We have started preparing our Linux kernel to be based on the grsecurity kernel. This is available as a package in the beta’s repositories but is not enabled by default, as we consider it requires more testing (you can help!) so we can use it as the default Linux kernel in the future (for PureOS 3.0’s final release, hopefully!)… so feel free to install and try it out (don’t forget to install paxctld as well)! This will be a huge step forward in terms of security. While most regular GNU/Linux distributions are more secure and privacy-respecting than proprietary OSes, having the grsecurity patchset in PureOS’ Linux kernel by default will bring PureOS far above the norm in terms of desktop GNU/Linux security practices.
  • We look forward to integrating flatpak in the future to benefit from its sandboxing capabilities

As you can see, we’re making some nice progress and PureOS has great plans ahead to achieve a great user experience that balances security and usability. This is quite a bit better than running OSes that work against you or that strip you of control over the applications layer!