Tag: Phones

Ethical aesthetics – Librem 5 design report #7

You may have noticed that there is no obvious visual branding on the Librem laptops. While this was at first a technical limitation on the very first Librem model (back in 2015), the subtle and minimalistic branding that began on newer models in 2016 was a conscious design decision.

Now, we’re hoping to refine the physical branding further.
One reason for a minimalist design is aesthetic. Just like on a piece of hand-made jewelry, we wish the branding to be made in the form of an inconspicuous marking that doesn’t interfere with the natural beauty of the overall shape.

Another reason is ethical. While one should easily be able to identify a computer model when closely inspecting it, people using a Librem device should be prevented from, unintentionally, exposing the brand of their hardware, which may be seen as arrogant in some situations. But, above all, the Librem customer should not be used as a passive promoting medium. We think that this is an essential part of an ethical design.

This is described within our internal industrial design policies in term of visual identity, so I think important to emphasize those points.

Branding on the Librem laptops

Therefore, on the current Librem line, branding is only visible on the keyboard (with the “Super” key displaying the Purism logo) and on the bottom cover, displaying the brand and model name, along with certification symbols, underneath the computer.

That said, while not being visible during normal use (open on a table), the bottom branding of the Librem may be considered a bit flashy when carrying the laptop around, so we are considering making it even more discreet in the future.

Branding on the Librem 5

The Librem 5 is not in production yet but the public mock-ups have been escaping that rule so far. While I think that it was important for everyone to easily identify the device mock-ups during the campaign, the final model should not display any branding on the back cover of the handset. Instead we are discussing the possibility of having the brand and model number carved on the side of the device.

Designing the scope of the Librem 5’s communication apps

We have spent the last few weeks focusing on the design of the default communication features of the Librem 5. As part of that process, we came up with the design specification for two applications. One of them is called “Calls” and has been designed for the purpose of—you guessed it—making and receiving phone calls. The second one, called “Messages” has been designed for the no less obvious purpose of sending and receiving messages.

Tobias, our lead designer, does a great job in communicating and collaborating with the GNOME design team, and so we keep making progress jointly with the upstream GNOME project. When Tobias joined, we started by having a call with Allan Day and Jakub Steiner (from the GNOME design team) where we presented our project, our goals and discussed the way to structure our contributions to GNOME. For example, we have an app design repository on the upstream GNOME GitLab server, where our design and mock-ups are made available to everyone. All in all, our project and vision seem to be very well received by the GNOME community.

The “Calls” application

This application is not based on any existing application so we had to design it from scratch. We did so while Bob was making good progress on implementing the basic cellular call features.

“Calls” is supposed to let the user handle regular phone calls but is not limited to that. It is designed to integrate a much higher level of security and privacy through end to end encrypted technologies in a very transparent way. Private calls, between two devices supporting that feature, would be made by simply selecting a contact and pressing the “call” button.

The full design of the Calls application can be seen in its own repository.

The “Messages” application

At the beginning of the summer, some Purism members (Dorota, Adrien, Tobias and myself) participated in the Fractal hackfest in Strasbourg. The goal was to analyze and discuss the possibility of having Fractal become the default messaging application on PureOS and the Librem 5. This is motivated by our wish to be in sync with upstream choices as well as with the fact that Tobias, besides being the designer for the Librem 5 applications, is also the designer of Fractal. We also took this opportunity to meet Matthew from Matrix who provided very helpful technical clarifications about the Matrix technology.

It was clear in this meeting that Fractal’s future plans are aligned with the Ethical Design principles, that the Librem 5 and PureOS design guidelines are based on. An application following those guidelines, must be simple and focused on a single purpose.

One might think that the current state of Fractal already fits the main purpose of the Messages application (sending and receiving messages), but it is actually too general in terms of purpose. Chatting privately with a friend is not the same as discussing in a crowded IRC like public room. While the back-end technology may be the same for both situations, the user interface may have different requirements. This was discussed at the Fractal hackfest (Tobias used the analogy of the “barbecue” and the “banquet” to expose the problem), where Fractal developers decided that Fractal should be split into two distinct applications; one application would be used for the purpose of private 1 to 1 and small group chats (the barbecue), the other one would be used for the purpose of crowded IRC like discussions (the banquet). It will take a while for that split of an existing application to happen, however.

The simplified Messages application we have been developing is based on the “barbecue” usecase; private 1 to 1 and small groups chats, the most common usage for the majority of the population. The plan is for the Messages application to be able to handle regular text messages (SMS) while also handling secure end-to-end encrypted messages in a transparent way between two compatible devices.

The full design of the Messages application can be seen in its own repository.

Librem 5 general development report — July 16, 2018

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!

Solving the first FSF RYF hurdle for the Librem 5

While investigating using the i.MX 8 for the Librem 5 phone we found an issue that would have been problematic for us to obtain the Free Software Foundation’s “Respects Your Freedom” (RYF) hardware endorsement:

  • In U-Boot there are a number of firmware blobs that need to be loaded into the DDR PHY so that it can be trained to work with DDR4. This training is done on every boot.
  • The normal boot sequence for the i.MX 8 is that the internal ROM loader loads the Secondary Program Loader (SPL) which, in this case, is a small version of U-Boot that can initialize the DDR and load the full U-Boot into DDR to finish the boot process. Very early in the SPL, the training blobs get loaded into the DDR PHY and the training sequence is run. The DDR training procedure is completely un-documented so re-writing the firmware blobs with free/libre or open source versions would be an arduous process.
  • We can’t ignore the DDR PHY because it is interface between the i.MX 8 internal buses and the DDR4 chips outside of the SOC. The DDR PHY is also part of the i.MX 8 silicon so we can’t just replace the DDR PHY with a different one. It also appears that all DDR PHY’s required this training to work with DDR4, so going to a different SOC wouldn’t solve it either.

The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel. Read more

Librem 5 general development report — June 11, 2018

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.