Latest posts by Heather Ellsworth (see all)
- Librem 5 general development report – Updated August 6, 2018 - August 3, 2018
- Librem 5 general development report — July 16, 2018 - July 16, 2018
- Librem 5 general development report — June 11, 2018 - June 11, 2018
The Librem 5 team has been a busy group with GUADEC along with lots of exciting development changes. Here’s a summary of what has been going on with the Librem 5 team the last few weeks.
Recently most of the Librem 5 team members attended GUADEC. Some of the Librem 5 attendees gave talks as well. Since many of the talks are still being edited, here are a few of them for your viewing pleasure:
- Input methods, wayland and upstreams by Dorota Czaplejewicz
- Designing GNOME Mobile by Tobias Bernard
- Making a Phone Call with GNOME by Bob Ham (jump to the actual phone call demo)
- Librem 5 BoF session notes
There were also talks given on security items and implementing phone UIs with GTK+. We’ll link to those talks when the editing is complete.
The Librem 5 will look beautiful but that doesn’t come without effort. Lately, our design team has been hard at work on a new icon style for GNOME 3.30 that will be used by the phone. They have also been working on expanding the mockups for the cellular settings panel with more advanced features as well as more detailed work on the shell.
The images were taking a long time to build so we were able to cut down the total build time by making a few tweaks. This makes development and testing a little nicer. There was also the first prototype aarch64 build with PureOS wich worked well. The images haven’t completely shifted over to PureOS as a base (instead of Debian buster) but that is coming real soon. If you’ve been running the x86_64 VM, then you’ll be happy to know that recent images allow you to resize your rootfs to fill a larger (31GB) space. This will make development much easier since previously the image was only 3.6GB. There is still work to be done on resizing the rootfs but it’s in a usable state now.
Phosh has seen many under-the-hood improvements in the form of bug fixes, like several potential crashers and missing initializations. Also the brightness slider was fixed to behave properly when moved.
Wayland global handling was moved into a separate GObject. A lockscreen-manager object was introduced to unclutter things (it also picks up the timeout form GSettings now) and all remaining Layersurfaces were converted into PhoshLayerSurfaces.
It’s these code clean ups that really pave the way for community contributions because the more organized code is, the easier it is to understand and contribute.
The integrity of phosh is critical since it is the phone shell so a gitlab smoketest has been added to run phosh under Valgrind. Also it’s just a start to our eventual language support, but Spanish and German translations have been added.
And there were some odds and ends fixed up in phosh too. As we mentioned in the last progress report blog post, there was some ongoing redshift work. This code was merged to master including a fix for race conditions when listing video modes. Phosh/wlroots now starts via gnome-session and a (software) home button was added to the bottom of the screen.
In the land of wlroots there were also plenty of under-the-hood changes. Some custom video mode patches were merged upstream to allow any custom video mode to be defined. Since the Librem 5 will ultimately not include X support, we needed to remove the dependency on xwayland. So now wlroots is built both with and without xwayland support. A wlroots freeze has also been found to be caused by one logging out of the ssh session that started wlroots and there it is awaiting some upstream discussion on how to handle this.
The keyboard (virtboard) will ultimately benefit from the great text-input protocol work that has been recently worked on. The text-input-v3 patch has also been updated and sent upstream to Wayland for review. An implementation of the text-input protocol for GTK3 was submitted upstream and is a work in progress. For wlroots support, a recreated implementation has been drafted, soon to be submitted for review.
In order to integrate Calls with the gnome-settings-daemon and gnome-control-center, it became clear from discussions at GUADEC that the best path forward was to switch to using ModemManager instead of ofono. So even though the testing thus far has been with an ofono implementation, this was an unavoidable necessary change. The initial implementation of ModemManager backend of Calls was completed and has started undergoing tests.
The UI of Calls has made some strides to look like the mockups from the design team. Below you can see the implementation (left) next to the mockup (right).
Some more bugs were fixed in libhandy too as well as more preparation for GTK+4. One of the issues found and fixed was memory leak was found and fixed. Also there was a bug found and fixed in HdyColumn where the wrong width was being used for column height calculation.
If you are following the librem-5-dev email list, then you may have seen that libhandy v0.0.2 has been released too!
The phone will ship with an SMS app which also has E2EE messaging. We are working with the Fractal project upstream to get encryption implemented, but it’s not clear whether the Fractal 1-1 successor app (GNOME Messages) will have all the things we need by launch. For a more detailed analysis of Fractal’s role on the Librem 5 read the Banquets and Barbecues blog post.
This is why “Chatty” (code name) is being developed by Purism, a new chat application using a libpurple backend, which will contain E2EE of XMPP messages via OMEMO from day 1 (when Librem 5 phones are shipped in January), as well as non-encrypted SMS. Since the revelation that ModemManager is needed instead of ofono for the Calls application, a D-BUS handler was created for the ModemManager backend of the messaging app. With this ModemManager setup, sending and receiving SMS is working so far!
Security is one of our favorite things (maybe you’ve noticed) so some research was done on TrustZone, TPM and other related topics. There have also been some internal discussions about tamper-resistant boot, Heads, and alternate USB modes for video output. So we’re really starting to think hard about implementing security measures for the Librem 5.
It is no small feat to get a working kernel and drivers ready for the i.MX8M board. With lots of hard work, we now have ethernet working. As a requirement for DRM and graphics support, the PCIe has been forward ported. The second SD port is now working but not SDIO yet (the SDIO board is powered by USB so need to get USB working first) so working on getting the designware USB core working. More i2c devices have been enabled. The board will also need some sort of battery charger and the one being tested now is the BQ25896 from TI, but a power supply driver had to be added and submitted upstream.
There is still a long road ahead towards getting the kernel and all of the drivers in working order, especially on the graphics front. If there are any graphics driver experts out there willing to lend a hand, please reach out to us in the Matrix chat rooms.
We’re still working with our potential manufacturer of the development boards to review the schematic developed by the Librem 5 hardware engineers and make suggested changes. However, many things are set in stone for the development boards and many parts have been ordered so here are some components you can count on being on your development board:
- SoM: EmCraft’s i.MX 8M System-On-Module
- Display: an LCD display that is 5.7″ at 720×1440 pixels
- Modem: SIMCom 7100A (USA version/bands) or SIMCom 7100E (EU version/bands) – depends on where you live
- WiFi+BT module: Redpine RS9116 M.2 module. It supports 2.4GHz and 5GHz bands for WiFi, no 802.11AC
- Camera sensor: the CMOS image sensor chip is the Omnivision OV5640
There is a new FAQ up on the developer documentation site, just based on some repeat questions we’ve seen in the community/librem-5 matrix channel. We are not aiming to answer ALL questions here that you can think of because that would require too much time but rather we’re adding questions that are just commonly asked.
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!