Tag: Phones

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!

Last Call for Librem 5 Dev Kit: order yours before June 1st 2018

Purism has finalized the specifications for the Librem 5 development kit and will be placing all the component parts order and fabrication run the first week of June 2018. If you want to have early access to the hardware that will serve as the platform for the Librem 5 phone, you must place your dev kit order before June 1st, 2018. The price for the development kit is now $399, up from the early-bird pricing that was in effect during the campaign and until today. The dev kit is a small batch, “limited edition” product. After this batch, we are not planning for a second run (as the production of the phone itself will replace the dev kit in 2019).

Improved specifications

We decided to wait to get the latest i.MX 8M System On Module (SOM), rather than utilizing the older i.MX 6 SOM, therefore having the dev kit align nicely with the ending phone hardware specifications. This means the dev kits will begin delivery in the latter part of August for the earliest orders while fulfilling other dev kits in September. Choosing to wait for the i.MX 8M SOM also means our hardware design for the Librem 5 phone is still on target for January 2019 because we are pooling efforts rather than separating them as two distinct projects. Our dev kit choices and advancements benefit the Librem 5 phone investment and timeline.

The current dev kit specification is (subject to minor changes during purchasing):

  • i.MX 8M system on module (SOM) including at least 2GB LPDDR4 RAM and 16GB eMMC (NOTE: The Librem 5 phone will have greater RAM and storage)
  • M.2 low power WiFi+Bluetooth card
  • M.2 cellular baseband card for 3G and 4G networks
  • 5.7″ LCD touchscreen with a 18:9 (2:1) 720×1440 resolution
  • 1 camera module
  • 1 USB-C cable
  • Librem 5 dev kit PCB
    • Inertial 9-axis IMU sensor (accel, gyro, magnetometer)
    • GNSS (aka “GPS”)
    • Ethernet (for debugging and data transfer)
    • Mini-HDMI connector (for second screen)
    • Integrated mini speaker and microphone
    • 3.5mm audio jack with stereo output and microphone input
    • Vibration motor
    • Ambient light sensor
    • Proximity sensor
    • Slot for microSD
    • Slot for SIM card
    • Slot for smartcard
    • USB-C connector for USB data (host and client) and power supply
    • Radio and camera/mic hardware killswitches
    • Holder for optional 18650 Li-poly rechargeable battery with charging from mainboard (battery not required and not included!)

The dev kit will be the raw PCB without any outer case (in other words, don’t expect to use it as a phone to carry in your pocket!), but the physical setup will be stable enough so that it can be used by developers. As we finalize the designs and renders we will publish images.

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

Librem 5 design report #5

Hello everyone! A lot has happened behind the scenes since my last design report. Until now, I have been reporting on our design work mainly on the software front, but our effort is obviously not limited to that. The experience that people can have with their physical device is also very important. So in this post I will summarize some recent design decisions we have made both on the software side and the hardware product “experience” design.

Thinking about the physical shell

Our goal with the Librem 5 is to improve the visual identity of the Librem line while staying close to the minimalist and humble look that characterize the existing Librem line.

The main challenge of case design is the need to balance aesthetics, ergonomics, convenience, and technical limitations.

As you know, the Librem 5 is a special phone that will not integrate the same CPU and chipsets as usually implemented in the vast majority of smartphones in the market. Power consumption is a very important factor to take into account, but so is battery capacity and printed circuit board arrangements, and we don’t want to sacrifice battery life for a few millimeters of thickness. Therefore:

  • We are now aiming for a 5.5″ to 5.7″ screen with a 18:9 ratio that would let us incorporate a larger battery without affecting the shape of the phone.
  • We are also opting for a shape with chamfered edges (as pictured below), instead of the usual rounded ones. Not only do we think it looks elegant, the general shape would provide a better grip and it give us a bit more room inside for components.

Simplifying the UI shell

As the implementation of the Librem 5 goes on, we are quite aware that time is limited given our January 2019 target, and we are therefore focusing on robustness and efficiency for the first version of the mobile UI shell (“phosh”), which we wish to push upstream to become the GNOME mobile shell. As you may recall from our technical report from early March, we had discussed with GNOME Shell maintainers, who recommended this clean-slate approach.

We revisited the shell features and decided to split the design and implementation into several phases.

Phase 1 defines a shell that is at its simplest state in term of features and usability. This is the shell that should ship with the Librem 5 in January 2019.

This shell includes :

  • A lock screen.
  • A PIN-based unlock screen for protecting the session.
  • A home screen that displays a paginated list of installed applications.
  • A top bar that displays useful information such as the time, battery level, audio level, network status…
  • A bottom bar that simulates a home button (only visible when opening an application).
  • A virtual keyboard.
  • Incoming call notifications.

The “call” app is indeed a special case application on a phone, and that’s why we’re prioritizing it for the notifications feature: it has to work from day one, and it has some requirements like the ability to interact directly on the lock screen (to answer an incoming call, or to place an emergency services call).

Multitasking UI workflows, search and more flexible app notification features/APIs should be implemented during phase 2, available a bit later.

While “phase 1” might not be the all-you-can-eat features buffet some may be accustomed to, we think that this minimalist shell will be extremely simple to learn, use and will favor a quick and painless adoption. And it’ll be a great starting point.

Designing the Contacts application

The Contacts application will be at the center of the communication features. It is the application that will handle the contacts management that other applications such as Calls or Messages will rely on.

For that matter, we are adapting the existing Contacts application by designing its mobile layout and adding extra fields that will be required by the different communication applications.

Librem 5 & Fractal team hackfest in Strasbourg

This week, a few members of the Librem 5 team (including myself) are attending the 2018 Fractal design hackfest in Strasbourg, with the goal of helping the Fractal team to make a beautiful and secure Matrix-based IM application to be used on both the desktop and mobile platform. I hope to do a report on the communication features of the Librem 5 in a future post where I will talk about what happened at the Fractal hackfest.

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.

Design report #4: symbiotic applications

Purism’s long-term goal has always been to make computers that are as convenient as they are respectful to the people that use them. The Librem products are an ethical platform and therefore should not be discriminating anyone; instead, they are meant to be inclusive of all human beings. In other words, everyone should find in their Librem a convenient and secure platform for their daily usage, and therefore accessibility should also be an important part of our ethical design roadmap.

We are aware that the road is long and that the Librem 5 is a challenging project, so we need some design foundations that favor convenience as much as it can lighten the development effort to get there.

Apps on existing platforms compete for your attention

With today’s smartphones, you usually get a minimal set of functionalities out of the box and go through installing diverse applications for your different needs. Usually those applications are proprietary and are designed around their own unethical business model; hence they compete against each other for your attention and have their own set of features to be used within the scope of the application only.

This can lead to a lot of redundancy and confusion in terms of functionality. A particularly blatant case is communication applications, where we see each application handling their own contacts logic, their own locked down and isolated protocol, and where a ton of applications will implement the same things for the same purpose (making calls and sending messages), with the focus typically being the flashiest application to attract and retain the most users. Let’s illustrate how ridiculous this is, conceptually:

Envisioning a harmonious app ecosystem

In the real, natural world, sustainable ecosystems are made of biological entities interacting together in harmony or symbiosis. This is what makes life possible over the long term.

The digital world of Free/Libre & open-source software, particularly in operating systems, is highly similar to the natural ecosystem. In this world, there is no such thing as isolating off or protecting a technology if you want to be part of the system. Business models and interests are completely different from the world of proprietary software. Best practices favor reuse and integration, improving user experience, reducing technical debt, increasing software quality and lowering development costs, with a “collaborative” system where different applications from different authors are made to work together.

The Purpose is the Feature

The idea behind the PureOS design guidelines is to replace the concept of standalone, independent and feature-competing applications with a concept of small, single-purpose, cross-integrated applications—that would interact between each other to provide a unified experience across the device (and beyond). Those small applications can be seen as “features” of the system. 1 purpose = 1 feature.

Therefore, the Human Interface Guidelines’ main principles regarding “features” development would be :

  • Don’t see applications as independent programs but as “features” that have a single purpose and that interact with each other.
  • One “feature” application is guarantor of the security of the data flow going through it. Only make your “feature” application share data with “trusted” features or networks and in a secure way.
  • Make a “feature” application focused on one single purpose (an email client is not an address book nor a calendar)
  • Make your “feature” application rely on existing features (an email client should rely on the existing address book and the existing calendar “features”)
  • Avoid redundancy. Don’t try to reinvent existing applications. Improve them instead.
  • Setup your “feature” application by default. Make it work out of the box.

Advantages

On the user’s side, the features of the device are easy to spot as they are made available through single-purpose applications displaying an obvious name. For example, the “Call” application is made to make calls, no matter the technology used behind that (e.g. Matrix, phone, voip). The “Messaging” application is used to send instant messages, no matter the technology used behind that (e.g. Matrix, SMS, XMPP). The “Contacts” application is used to manipulate and store the contacts information to be used by the “Call” and “Messaging” applications.

On the developer’s side, applications are as simple as they can be, the use cases are limited, all the logic that is not related to the main purpose of the application is delegated to other programs, which makes the application easier to design, implement and maintain.

Data belongs to the user, not the application

In this collaborative application system, where applications can interact with each other in harmony, data is not limited to the application’s logic anymore. Applications are acting as services, or “data providers”, to each other. Data can flow from one application to the other, from one device to another, from one network to another.

This concept implies the separation between data and functionality where the data belongs to the user only. The application that manipulates it is guarantor of its integrity and security.

Please note: these are guidelines, representing an overall vision. Guidelines are there simply as a way to guide application design, and to suggest best practices for application developers in general. Given that a GNU+Linux distribution like PureOS is an open platform where thousands of applications are available independently (as long as they are freedom-respecting!), you are not obligated to conform to these design guidelines to be able to distribute your application through Debian and PureOS. Furthermore, these design plans represent a broad long-term plan, not necessarily a guarantee of what will be happening “immediately” in the first released version of the platform that ships, your mileage may vary, etc.