Category: Software

Librem 5 progress report #15

These last few weeks, the Librem 5 team has been hard at work improving the current software stack as well as making great strides towards finalizing the development kit schematic. Here are the highlights of the exciting progress that has been made.

Software Work

Images

The images produced for the i.MX6 board now have phosh as the default shell and we are experimenting with PureOS as the base OS (instead of Debian buster). There is also now an x86_64 raw VM image being produced and you can follow these instructions on getting a copy of the image and running it. The VM image uses the same screen resolution that the actual Librem5 phone will use.

While the i.MX6 images have been developed for the current hardware in the team’s hands, work continues on the image to be used on the i.MX8-based development board and actual phone. Note that during the investigation of the i.MX8 CPU, there were freedom issues that needed to be addressed. To read more about this, checkout the Solving the first FSF RYF hurdle for the Librem 5 blog post.

The image built for the i.MX8 board can now boot a very basic mainline kernel (instead of the vendor kernel offered up by the manufacturer). The next steps are to bring more components (like the display) online and to upstream these changes. All in all though, this i.MX8 image is really coming together!

Phosh/wlroots

At some point, most people will likely use their Librem 5 at night so having redshift in place makes the screen easier on the eyes. There was some work done to implement some of Mutter‘s DBus API in phosh, needed for e.g. display configuration and redshift. So now, phosh can detect the attached outputs and supported video modes and report them in a mutter/gnome-shell compatible way so they show up in gnome-settings and gnome-settings-daemon is happy. This is the base for future gamma control work (redshift). This depends on a patch to wlroots which is currently under discussion.

Other phosh usability improvements have been made as well. The lock screen timeout has been increased to allow for a bit more time to log in. Also, the favorites / home screen handling has been corrected to properly wrap columns and add scroll bars when necessary.

Since phosh is the shell and it works hand-in-hand with wlroots, they both are key areas for the image development. There have been frequent updates to wlroots to stay current with the upstream snapshots. A minor issue was fixed in upstream wlroots to improve the error handling of compiling for armhf. Also support for adding custom video modes has been added to wlroots. Work on Gcr system-prompt integration is being done in phosh. This  will solve a heap of authentication and modal dialog issues with PINs, PUKs, passwords, smart cards and keyrings by leveraging what’s already in GNOME.

Keyboard

There has been ongoing work into the onscreen keyboard (virtboard) which has led to virtboard being included in the images. In order for virtboard to show/hide when needed, merging of an input method (text-input) into wlroots was needed and GTK+ upstream was contacted about upstreaming the input method code. We are working on a patch securing the input method in our compositor. There has also been continued feedback from upstream on upstreaming the virtual keyboard protocol. The keyboard scales much better now too!

Calls

The calls application has also been added to the images for easy access. Within the calls app, the sending of DTMF tones has been added so that you can now hear those familiar sounds when touching a number on the keypad.

To make calls more robust, the possibility of doing unit tests of Calls’ oFono provider backend using the phonesim simulator were explored but unfortunately running ofonod requires root privileges in order to  take ownership of the well-known name, org.ofono, which makes testing a massive headache if not impractical. Still though, unit tests for the Calls Provider interface using the dummy implementation, as well as tests for Origin and Call interfaces have been added.

Libhandy

The libhandy GTK+ widget has seen some growth too. HdyColumn has been added to help out with dynamic column resizing. There have also been some unit tests added for HdyArrows (used for directional swiping). A first version of libhandy has been released and v0.0.1 has even been uploaded to Debian experimental!

Epiphany/GNOME Web

The web browser on the Librem 5 will be Epiphany so adaptive changes have been merged upstream to improve the usability on small screens. An in-window app-menu for Epiphany has started to be implemented and is still a work in progress.

Messaging

A demo app for libpurple has been drafted and an XMPP conversation has been established between the demo app and Dino. For encryption, an OMEMO conversation running with libpurple and the Lurch plugin was established. There has also been a conversation-view that pulls avatar/account data from a buddy list stored in xml. The ofono interface in SMS/XMPP was implemented into the demo app as well.

Hardware Work

External factors have caused our development board schedule to slip beyond our initial June projected ship date. While developing the schematic for the development board, not all information was readily available so investigations were needed on various components (e.g. cameras, WLAN+BT, batteries, switches, push buttons, etc), and circuits needed to be added before the schematic is considered ready for review by the third party that will print the boards. The Librem 5 hardware team has done all of these required tasks and are in the process of ordering parts to be sent to the manufacturer of the boards. Our current rough estimate for shipment of the development boards is August 2018 but stay tuned for a more detailed blog post on the subject.

Community Outreach

The Librem 5 matrix chat rooms have really exploded with lots of fantastic feedback and questions. Some community members have even stepped up to help find new issues, fix some issues, and  add to the documentation. Due to the demand from the community, there is now an x86_64 VM raw image available that looks just like what the team is installing on the i.MX6 boards.

The Purism collaboration with the Plasma community continues as well. There are now some arm and aarch64 flatpaks of Plasma software. The Purism team is also actively investigating building a Plasma image for the i.MX6 boards as well.

Developer documentation changes have also been made to better guide everyone to the right places:

  • The volunteers page has been updated with more clear instructions on how to participate.
  • Regardless of the type of board (whether physical or emulated), common steps have been added to a first steps page.
  • There are now instructions on setting up the x86_64 VM image.
  • Contribution guidelines have been posted to demonstrate the preferred communication processes
  • A GTK+ page has been added with example apps and includes documentation on adaptive labels.
  • A phone constraints page has been added to outline some specific constraints that should be considered when developing apps for the Librem 5 phone.

We also recently attended the GUADEC conference in Spain where we got to interact with a lot of wonderful folks excited about the Librem 5. More on the GUADEC conference to com in a future progress report.

A big Thanks goes out to all of the external teams that have helped review and merge changes into upstream projects. Everyone’s time and contribution is much appreciated!

That’s all for now folks. Stay tuned for more exciting updates to come!

What is PureOS and how is it built?

PureOS is a general purpose operating system that is based on the Linux kernel and is focused on being an entirely Free (as in freedom) OS. It is officially endorsed by the Free Software Foundation. We adhere to the Debian Social Contract and the GNU FSDG.

PureOS aims to match and surpass mainstream operating systems (such as Windows and macOS) by striking the balance between security and usability, to provide the best possible out-of-the-box experience paired with the best privacy, security, and software freedom protections possible. The idea is to make it easy to feel safe and secure with an operating system you can trust from the ground up and with appropriate tools. Read more

Librem 5 progress report #14

There has been some exciting work done on the Librem 5 project and while there is still plenty of work left, we would like to highlight the accomplishments the team has achieved over the last couple of weeks. So here please enjoy a brief update on our recent efforts and victories.

Software Work

There is so much that goes into the software stack of the Librem 5. There’s the underlying infrastructure like the UI shell and newly developed libraries and protocols. But then there’s the familiar apps that are necessary.

On the nuts and bolts level, our phone shell (phosh) has seen several usability improvements mostly around the lockscreen. One important change is that the lockscreen unlocking has been switched to PAM to better handle the PIN to lock the device. There have also been some additions to the code to better handle multiple outputs (screens). Also, Libhandy is our “handy” UI library for developing GTK+ apps. There has been a recent addition of an arrows widget (HdyArrows) to indicate swiping direction which will be very useful to many applications, especially the lockscreen. Additionally, libhandy has seen some bug fixes and a slight rework of the keyboard handling support. Since graphics are important, we have added Etnaviv support to weston-simple-dmabuf (a Wayland client to test Linux DMA-BUF protocol implementations). We also extended it’s NV12 format support. It’s being used over here to test wlroot’s linux-dmabuf implementation which we wrote a couple of weeks ago. We’d like to especially thank the wlroots and Weston projects for their code reviews, recommendations, and support.

Since you can’t have a phone that doesn’t make phone calls, there have been great strides made on the Calls app and the Calls app can successfully place phone calls now! (And if you missed it, we encourage you to go read the exciting blog post about it.) Along with all of the great work it took to get to this point, the interfaces have been documented in the code. Debian packaging is being put together and we’ve been working to include Flatpak packaging contributed by a member of the community.

Every smart phone needs an On-Screen Keyboard (OSK), so there has been significant development on writing some necessary protocols and getting them upstream. So far the virtual-keyboard protocol has been accepted for inclusion in upstream wlroots. The text-input protocol has also been submitted upstream. To test virtual-keyboard protocol, we created a prototype client based on weston-keyboard. You can read more about the OSK developments in Dorota’s initial blog post on the matter.

Hardware Work

Identifying and testing the individual hardware components that will be present on the dev kit and eventual phone is a non-trivial task. After identifying a component as a potential fit for our needs and receiving a couple of them to test, often kernel modules need to be modified or written before the testing can begin. This was the case when evaluating and testing a low power WiFi card/module, which is still underway. Vibration motors are also being gathered for evaluation and battery chargers are being tested. We are also looking into various camera options.

Community Outreach

The community continues to be at the front of our thoughts. So we have created a general PureOS wiki at wiki.puri.sm that still doesn’t have much details yet but will eventually be a place to look for both general and technical information on PureOS and Purism products. We’ve also fixed an issue with the community email lists so that they are functional now and opened up our Matrix rooms so that you can join our discussions with your already existing Matrix ID. For more information on both the email lists and Matrix rooms, have a look at our volunteer page.

We have been so happy to receive some initial volunteers that are doing fantastic work to help the Librem 5 become awesome. If you’ve been following and contributing to our code repositories, please note that we just moved the hosting from Gogs to GitLab – the new location can be found at source.puri.sm.

That’s all for now folks. Stay tuned for more exciting updates to come!

Introducing Calls on the Librem 5

Introduction

Arguably the most critical functionality in a phone is the ability to make and receive calls through the Public Switched Telephone Network (PSTN), that is normal cellular calls using phone numbers. While at Purism we are eager to implement communication systems that enable much greater privacy and security than one can expect from PSTN calls, the PSTN is still the most ubiquitous network and for the time being we can’t very well go around selling a phone that isn’t able to make PSTN calls. Read more

Initial Developer Documentation for the Librem 5 Phone Platform

At Purism, we are just as excited as you are about the the development boards that will be distributed this summer. Once a person receives their development board, their first thought will be “This is great! Now, what do I do with it?” In anticipation of the technical guidance that will be needed, the developer documentation effort has begun. You can already see the current state of the documentation at developer.puri.sm

Goal of the Docs

The developer documentation is there as a guide for getting a new developer setup and ready to start having fun! This will include plenty of examples that will help you along towards whatever your goal with the development board may be.

There will be technical step-by-step instructions that are suitable for both newbies and experienced Debian developers alike. The goal of the docs is to openly welcome you and light your path along the way with examples and links to external documentation. These examples will aid you from the start of unpacking your development board to building and deploying flatpak applications to it—and eventually including your package into PureOS. Included, you can expect examples on how to use certain tools like flatpak, the IDEs used to build flatpak applications, and UI tools to help you design apps. The design of the Librem 5 phone interface will also be outlined in detail to provide insight into the human interface guidelines that will be followed by the core applications. Use the design section to learn about gestures you can expect on the phone. Apps you design or port to the board can use these gestures too!

Please note that the docs are not a complete tutorial on how to use all of the development tools required. There are existing documentations available for each specific tool so there’s no need to reinvent the wheel. Instead, you will be directed to those locations online so you can research further on a specific tool.

We welcome all test and development efforts that volunteers have to give, so there will also be information on volunteering and how to become a Purism community member in general.

Work in progress

The documentation is in a constant state of flux. Content is being added daily and reorganization still occurs from time-to-time. If you no longer see a page there, just search for it because chances are it has been moved to somewhere else within the site instead of removed. The aim is to write documentation that is helpful and intuitive so it is important that an intuitive path is laid out. This developer documentation is still pretty new but is filling out quickly so that you are ready to hit the ground running with your new development board in June!

There will be a separate announcement in the next few weeks on this same blog to call for volunteers so get ready!

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 https://developer.puri.sm/PlasmaMobile.html.

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.

Therefore:

  • 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.


Update/P.S.: for the GNOME side of things, we are in close collaboration with upstream GNOME, and have followed GNOME Shell maintainers’ recommendations to have a simpler, Wayland-only shell (“phosh”) developed. You can learn more about it in our 2018 March 3rd technical report, in the “Compositor and Shell” section. So rest assured, those decisions have been taken with the “blessing” of upstream, based on purely technical grounds.