Show someone you love them - buy them a Pinephone!
Look what arrived on my desk just in time for Valentine's day!
It's a Pinephone, the KDE community edition to be exact.
Will this be the beginning of a long term relationship, or will we drift apart after the first date?
Background information and preamble
For those of you who have been living under a rock for the last few years and haven't heard of the Pinephone, think of it as basically like your typical ARM-based SBC in a smartphone form-factor. So yes, that means that it's a very open and developer-friendly design that will run an operating system of your choice, typically a Linux distribution. Sounds interesting, I'm sure you'll agree.
“Think of it as basically like your typical ARM-based SBC in a smartphone form-factor”
Now I'm not exactly what you would call a smartphone enthusiast, infact quite the opposite. I sit in front of a workstation all day, with ample opportunity and compute power to do all the number crunching I need to.
I've never understood why in the world I would want to pull out a smartphone and do these things in a much more limited way, ‘on the go’, when I'm out and about with other stuff on my agenda. Maybe I'm just well organised with my time, but I certainly don't feel as if I'm missing out on anything.
Nevertheless, there are obviously occasions when portable computing is indispensable. Personally I can think of three scenarios that make me want to investigate the possibilities of this Pinephone more closely:
Firstly, if I'm going to own a smartphone at all, it would be nice if it was more like a standard computer rather than a proprietary piece of junk. Transferring data in and out of it over the ethernet with sftp instead of copying it to and from a fat-formatted USB flash drive would be nice, and what about actually having raw access to the files containing SMS text messages, for backup and transfer to another device? Count me in for sure. Oh, and does it also mean that I can place voice calls and send SMS just by ssh'ing into my phone and using the shell? I'm starting to like the idea already.
Secondly, even a small laptop can be inconvenient on a 12-hour long haul flight with no in-seat power, (yes, they do exist). As this phone can run a real OS instead of a toy OS, I can potentially use it for some light work in place of my laptop in these sorts of situations.
Thirdly, maybe the whole reason that I'm not into the whole smartphone culture is because, to put things bluntly, the mainstream smartphones on the market today are simply not geared towards those of us who've spent their lives working with real computers. I'm not impressed by flashy proprietary ‘apps’, or 40-megapixel cameras coupled with cheap plastic lenses that can barely focus an image at all. Manufacturers need to try much harder to catch my interest.
So with those points in mind, let's open up this Pinephone and take a closer look...
Hardware
Two versions of the KDE community edition have been produced, a basic model, and a slightly more expensive version that includes more RAM, a larger eMMC, and a USB docking station, known as the convergence package. I'm looking at the convergence package, and to be honest, I can't think why anybody would opt for the more basic model out of choice.
“I can't think why anybody would opt for the standard model over the convergence edition out of choice”
In the box, we find the phone itself, the dock, a USB cable, and not much else. Excellent. I really don't need yet another hands-free kit, or another cheaply produced charger of dubious quality. Plus one for sticking to the essentials and avoiding waste.
The phone uses a USB-C connector for charging. This is another move in the right direction, as we benefit from the convenience of a reversible connector that hopefully won't wear out quite as quickly with repeated connection and disconnection as the micro-USB connectors on my previous phones have tended to.
Specification
Convergence package
Standard model
SoC
Allwinner A64
RAM
3 Gb
2 Gb
eMMC
32 Gb
16 Gb
USB-C dock
✔
✖
Kill switches
✔
The USB-C connector also provides USB-2 data connectivity, (unfortunately not USB-3), and HDMI output, all of which is conveniently made available on regular ports by the dock included only in the convergence package. The dock provides a standard 100 mbit fast ethernet connection, too.
The specifications of the phone have been the source of endless discussion on-line, with various people complaining that it's too low-spec or whatever. Personally I don't agree with that. This is the first generation of Pinephone, and it's obvious that a lot of units need to get into the hands of a lot of developers for the whole project to become a success. The cheaper the device can be produced, the easier that is to achieve. It's plenty powerful enough to do useful development work on.
Having said that, here at Exotic Silicon, we do tend to prefer Rockchip SOCs over the Allwinner ones. I would have liked an RK3399 rather than the Allwinner A64, but that's definitely a small point, and I can work with what we've got. Also, from a technical point of view, a phone based on the RK3399 would probably have been a challenge for various reasons, so I can certainly see why they went with the Allwinner part.
Probably the weakest aspects of the hardware are the cameras, but they're not that bad as to be unusable.
Removing the back cover was easy enough, and I was surprised by it's solid feel. From the price of the phone, I expected the plastic to crack after a few removal and replacement cycles, but it's actually really nicely made. The KDE community edition has a chic KDE gear logo on the back cover, which looks to me as if it's laser etched, rather than printed. Certainly it hasn't chipped or faded after cleaning it a few times, which is nice.
The battery compartment has an indent that looked as if it should be possible to just prise the battery out, but since I don't enjoy breaking my fingernails, I resorted after a few attempts to tapping the handset against my open hand until it fell out on it's own. Apparently there is a screw that can be adjusted if the battery is a tight fit, but since I almost never needed to remove it after the first occasion, it wasn't an issue.
Crystal tip:
Crystal tip: Set the dip-switches before breaking your fingernails removing the battery.
There are six absolutely tiny hardware dip switches under the back cover, to physically disconnect the modem, wifi and bluetooth radios, cameras, and microphone. The last dip switch repurposes the headphone jack as a serial port, for use with a serial terminal. This might seem unimportant now, but will prove to be vital later on if I want to observe the early stages of the boot process.
The purpose and utility of these hardware kill switches, raises a question in my mind. If we're running an opensource operating system, and software that we trust, then surely the kill switches are now redundant? Don't get me wrong, I'd love to see this type of hardware disconnection on a mainstream smartphone, and I suppose it's a useful proof of concept, but coupled with the fact that they are so tiny and fiddly, and hidden behind the back cover, it doesn't really seem at all practical to keep, by way of example, the microphone disconnected all the time except for when you're making a call.
On the other hand, it might be an acceptable way to disable the cameras in a work environment where cameraphones are not permitted. The very fact that the dip switches are not easily manipulated could be a positive feature here, as it would be difficult to re-enable the camera without being noticed taking the back off of the handset and poking around with a small pointed object.
The phone accepts a single micro SIM. In the past, I've mostly preferred dual SIM handsets, but I can live with just a single SIM. Infact, since we'll be running a full and unencumbered open source operating system on the phone, the whole single verses dual, (or even more), SIM capability may well end up being rather moot. Since the audio from voice calls, and the content of text messages is just data, we could just transport it encrypted over the internet or any other suitable network, and forward calls from one handset to another in that way. So at least in theory, my second SIM could sit in a handset that I leave at home, or connected to the office ethernet, and when I need to call or text from that SIM, I just access it remotely. If you really need dual SIM support, it might even be fun to try connecting a second cellular modem via the USB port.
There seem to be very few people actually using a SIM in their Pinephone at the moment, or if they are, they don't seem to be actively talking about it on-line. This seems bizarre to me, as a phone isn't really much of a phone without active cellular service. It's just a PDA with a modem sitting idle. In the interests of thorough testing, I grabbed a 4G ready SIM with a generous data allowance on it that just happened to be laying around, to allow me to try out the cellular data capabilities of the Pinephone.
Software
First of all, I must admit that the Pinephone hardware interests me much more than the bundled software. If I was just going to use this device as a fancy featurephone, I probably wouldn't mind it running Linux, but as a serious portable computing device, for me, it would really need to run one of the BSD variants. Just saying.
The KDE community edition of the Pinephone runs, as you might expect, KDE Plasma mobile, but on a Manjaro linux installation, using Wayland as the windowing system. This is about as far away as you can get from my X11-based desktop workstation, so I'm coming to this with no pre-conceived ideas or expectations.
A multitude of other software distributions have been prepared and made available for download, but don't expect a large difference between them from a user-interface perspective, as many of them are just running the same UI on various underlying linux distributions.
At the time of writing, it's just been announced that this combination of KDE Plasma mobile and Manjaro linux is now going to be the default software installation on all Pinephone handsets going forward.
Using it as a phone, from an ordinary user's perspective
I'm going to look at the software on this device initially purely from the point of view of it being a cellphone, and concentrate on the interface, ability to make calls, send texts, and do other featurephone type things on it. Afterwards, I'll look into it more as a miniature laptop.
Visually, first impressions are good. There is only so much that you can do with a touchscreen interface on a cellphone, but the KDE plasma mobile interface gets a lot of things right. The multi-tasking view shows live thumbnail tiles of running applications, and the OS doesn't try to force you to keep everything you've opened running, as applications can be closed either with a UI button in the bottom right of the screen, or by tapping a tiny X on any of the tiles in the multitasking view.
I'm not easily impressed by pure GUI glitz, as I'm very much a CLI person who prefers to do everything at the shell. However this environment just feels right on a touchscreen device like a phone. Although I noticed occasional pauses and noticeably sluggish gui responses when opening new applications, it runs fairly well on the pinephone hardware. Don't get me wrong, it's not entirely intuitive, and I took a day or so to fully adjust to it. Once I had, though, I did begin to like it. Picking up an android phone after a day of using KDE plasma, I really felt that something was lacking.
“The software is now in beta, but it feels much like late alpha to me”
I should note at this point, though, that although the software is supposedly now in beta, it feels much more like late alpha release software to me. If I was doing a live presentation on the pinephone, I'd definitely have to plan my moves in advance to make sure the demonstration went smoothly. The system only actually deadlocked twice during two days of vigorous testing, but various long hangs, unexpected behaviour and occasional application crashes were definitely there.
Currently SMS text messaging mostly works, although MMS isn't implemented at all. The default messaging application is called spacebar, and is a very basic affair with the usual layout you would expect from an SMS program. Inbound and outbound messages appear in different colored bubbles justified to the left or right hand side of the screen. Yawn.
Crystal tip:
Accessing stored SMS messages
In case you're wondering, spacebar stores the SMS messages in a sqlite database in $HOME/.local/spacebar/messages.sqlite, so you can indeed copy them elsewhere, back them up, or do whatever you like with them. I wrote a script in about ten minutes to dump them neatly to a text file.
If you think this sounds trivial or boring, maybe you've never had a long discussion via SMS on an android phone that you later wanted to archive.
However, there seems to be an issue with locale or character encoding. Inbound SMS messages with multibyte unicode characters, such as emjoi, usually display incorrectly. Either the missing character glyph is displayed, or less commonly, the wrong glyph. The data does seems to be stored correctly in the database, though. Outbound SMS messages with multibyte characters usually never arrive at the destination, despite no error indication on the pinephone. If you stick to ASCII-only communications, you'll probably be fine ;-), but this could be a problem if you're communicating with somebody who uses emjoi as an integral part of their vocabulary, to the point where the meaning of their messages is unclear without those characters. Presumably this bug will be fixed at some point, as it's pretty obvious, but the fact that it exists at all suggests to me that few people are really testing the traditional cellular telephone features of this software.
Voice calls to and from the device worked, in as much as the audio was clear both ways during several test calls. However, the phone dialer is not rock-solid yet, and trying to use the Pinephone on a regular basis for voice calls at the moment would probably be frustrating. In particular the correct routing of audio to the earpiece or speaker is not really implemented correctly yet. The speakerphone button within the phone dialer is non-functional, but it's possible to configure the output device for use during phone calls from within the audio settings section of the settings application. I ended up leaving it set permanently on speakerphone for testing, because when I set it to earpiece, the phone rang quietly through the earpiece rather than through the speaker for incoming calls. This was fine for testing purposes, but it's probably not a practical option for most people.
“USSD codes are not supported in the dialer”
Sending USSD codes doesn't yet seem to be implemented within the phone dialer, which may be an issue if you rely on them for any network services, such as checking a prepaid credit balance.
The mobile wifi hotspot functionality didn't seem to work correctly at all, at least when configured from within the KDE plasma mobile GUI. The access point appeared for a few seconds, and the NWID was visible from another machine nearby, but the Pinephone disactivated it shortly afterwards, and I was unable to connect to it at any time whilst it was active.
One of the slightly unusual features of the GUI, that left me confused initially, is that the wifi option in the global pull-down menu doesn't only control access to other wifi access points, but also needs to be switched on if you want to use the Pinephone in host access point mode, as a mobile hotspot. Once I realised that, I actually liked it, as it seems more logical that you want to configure the wifi as either a client or host, then just have a global control to enable or disable the radio.
Other non-intuitive aspects of the GUI include that fact that changing the default light on dark theme to something more restful to my eyes was straightforward, but required changes in two completely separate parts of the settings control panel to achieve a global dark theme. The audio menu has various controls whose function is affected by the profile setting found in a sub-menu. So changing a sub-menu setting affects what you're doing in the menu above. That feels awkward.
One thing that I'm really not sure whether it's a bug or a feature, is that gui elements in an application are not selectable whilst the keyboard is active. This was particularly noticeable in the web browser, and when selecting blocks of text.
So my overall impressions of using KDE plasma mobile on the Pinephone, strictly for telephone-like functionality, are that it's potentially quite good. It's definitely not ready yet, but the interface is nice, and it seems like it could be a good experience once the software matures. Currently, there are still quite a few GUI bugs, especially with things like the keyboard popping up incorrectly, the backlight brightness changing by itself, and the lockscreen appearing seemingly at random sometimes, but looking beyond these bugs, which are mostly quite low-hanging fruit, the design of the GUI certainly has some things going for it.
One serious bug, though, is that the modem will from time to time, disconnect itself from the USB bus, and then re-connect. This dis-connection and re-connection is not handled well by ofono, which leaves the KDE telephony applications unable to access the modem. The only obvious way to restore access to the modem is to re-boot the phone. This is quite disruptive to trying to use the pinephone in any serious way when it happens every twenty or thirty minutes or so.
Software, using it as a miniature laptop, from a unix system guru's perspective
SPOILER WARNING
Things go downhill a bit from here on...
But what about using this Pinephone in a more computery fashion, as a miniature laptop, a PDA running Manjaro Linux? How does it measure up?
Well, the first step was to open the terminal application and see what I could do from there.
Immediately, I noticed that the default width of the terminal in vertical mode is less than 80 characters. This is seriously irritating, as just about every single CLI-based program written in the last 30 years expects an 80 character wide terminal at a minimum. Switching to horizontal mode fixes that, of course, but then the keyboard takes up almost half of the screen vertically, which is far too much to be practical.
“There really is something quite satisfying about seeing a shell prompt on a smartphone!”
Of course, the settings can be changed, and an 80 character wide display in vertical orientation does make the text quite small, but I still feel that it would be a more sensible default than a narrow terminal that the vast majority of CLI programs were simply not designed for.
Nevertheless, it was a big novelty and pretty satisfying to boot, to type ‘display’ at the shell prompt and watch ImageMagick load up on this smartphone. Sure, you can get image manipulation programs for mainstream smartphones, but those won't run all of the shell scripts I've written over the last few years to convert images for the web, create thumbnails, and do a lot of other repetitive tasks. Those scripts will mostly run unmodified on the Pinephone, albeit quite slowly. Still, if it avoids the need to get the laptop out on that 12-hour flight, it's served a useful purpose.
Installed by default were various familiar utilities, including The CLI flac audio encoder, perl, awk, (in the form of gawk), sed, and minicom to mention a few. I don't usually feel a burning desire to write a perl script when I'm out for a walk in the park, or waiting to pay for my purchases in the supermarket, but if I'm going to carry an arm cpu, 3 Gb of ram and a touchscreen around in my pocket, the device might as well be capable of doing these things instead of just running proprietary apps.
I was curious to see how secure this installation was by default, so I had a look at the list of listening sockets. The KDE connect app is automatically started by default and listens for incoming connections on port 1716 of all interfaces. Disabling it didn't seem to break anything. More concerning was that ssh was listening on all interfaces as well.
Given that the installation has a default username of ‘kde’ and a password of ‘123456’, it's clearly not exactly a great idea to have ssh listening for inbound connections via the internet-facing cellular data interface. Admittedly these builds are aimed at developers, but the default installation really shouldn't expose such an easily guessed default account via ssh. However, it gets worse, as the default root password is, literally, root. Direct root login with password authentication is disallowed by the default sshd_config, but from the default unprivileged account you can su to root with ease.
Maybe you're thinking that, to be fair, most cellular data connections don't provide a publicly accessible IPv4 address these days and so my concern would be unfounded. Firstly, I would point out that many cellular data connections do provide a globally scoped and fully routable IPv6 address, and I would also consider whether you completely trust your service provider themselves not to portscan your device over IPv4, which of course they could do, since the locally-scoped assigned address is obviously on their network.
In any case, I changed the root password to something more sensible, and made a note to restrict ssh to key authentication only once I'd uploaded a suitable key to the device.
I noticed that with an active SIM in the device, cellular data was automatically enabled after boot, even if it was previously switched off. This could be a problem for users of prepaid SIMs, as it creates a small amount of data usage on each boot, checking that the connection has global connectivity by connecting to known webserver specified in ‘/usr/lib/NetworkManager/conf.d/20-connectivity.conf’. Depending on the tariff and the way that rounding is applied to billing, this could create an artificially high cost for data.
Except, of course, that actually trying to connect to a data network at all is a bit of a hit-and-miss affair. Usually there is a significant delay of ten or fifteen minutes after switching on the cellular data service in the global top drop-down menu, before the connection is actually brought up and functional. Since the gui controls just seem to be a front-end to Network Manager, I tried running ‘nmcli connection up Internet’ from the shell, and was connected immediately.
“I honestly wonder just how many developers are actually testing this device with an active SIM”
Immediately, it was obvious that only IPv4 was being negotiated, but the reason wasn't clear. Accessing the serial port of the modem with minicom and issuing various AT commands, I could see that the PDP data context was set to request both IPv4 and IPv6 addresses, and the APN was correct. I know that the cellular provider fully supports IPv6, but I did test the SIM in another handset just to be absolutely sure, and IPv6 worked there without any problems at all. Clearly this is a software or firmware issue with the pinephone.
Crystal tip:
Making use of the status LED
Curiously, the LED indicator on the pinephone doesn't seem to be used for anything by default by KDE plasma mobile. It lights briefly when the handset is powered on, but this is done by the bootloader. If you want to customise this behaviour to maybe flash the LED a different color, you'll need to modify /boot/boot.scr.
Once booted, I found it most useful to set the LED to function as a read/write indicator for the eMMC, using a command such as:
By this point, after an hour or so of typing into a terminal on a virtual touchscreen keyboard, doing so was no longer a novelty. It was actually becoming quite tedious, especially with the sub-80-columns display. Apparently a physical keyboard for the pinephone, effectively making it into a kind of clamshell pda, is in the works. I would expect that to improve the terminal experience considerably, but for the time being, and considering that I also wanted to exchange some data with my desktop workstation, I decided to check out the connectivity options.
Networking mini-experiment
An idle server that was sitting on the LAN with not much to do, running OpenBSD 6.8, and with an unused wireless network card provided an excellent endpoint to test connectivity to the pinephone.
Since the pinephone is running a full Linux distribution, we can obviously set up pretty much whatever networking configuration we choose, including one that would not be directly supported by a mainstream smartphone.
With this in mind, I decided to configure a wireless access point on the server and have the pinephone connect to it as a client, but then configure the pinephone as a router to allow internet connectivity from the server via the cellular data connection.
“I was able to use the pinephone as a wireless router”
This was trivial to set up, and worked just as expected.
On the OpenBSD side, all that was required to configure an access point on the second wireless network card, with IPv4 address 192.168.64.2, using channel 6, was something like:
... obviously substituting an appropriate network identifier and key.
The pinephone was configured with a manual IPv4 address assignment of 192.168.64.1, and upon connection, I was able to connect to it via ssh from the server. By default, the wifi has a lower route metric than the cellular modem, so as expected, the pinephone lost internet connectivity once connected to the server. Unsurprisingly, the route metric isn't a property that can be changed from within the gui, but it's trivial to change it with something like nmcli connection edit Internet set ipv4.route-metric 10000.
At this point, I was able to upload an ssh key to the pinephone, and disable password authentication in ssh altogether. I set up IPv6 addresses on both interfaces too, for good measure, and was able to connect just as easily over the wlan using IPv6 as well.
Setting the default route on the server with route add default 192.168.64.1, and enabling IP forwarding on the pinephone with:
# sysctl net.ipv4.ip_forward=1
I was indeed able to access internet hosts from the server, using the pinephone as a router. I didn't manually set up any IP masquerading, and tcpdump showed packets going out to the ISP with the 192.168.64.2 address, so either it was somehow being done silently by the Linux networking stack, or the ISP just doesn't care which IPv4 addresses I use.
Of course, since we have the Linux USB gadget api, the same thing could be achieved via a USB connection rather than wlan. This would typically appear as either an urndis or cdce device on an OpenBSD machine, depending on the gadget configuration.
This was all very interesting, and it was nice to see the pinephone doing it, but without IPv6 working on the cellular data side of things it's of limited practical utility to me, so I moved on to looking at other things I could do with the pinephone.
CLI telephony for the poweruser
With the pinephone now connected to the lan, it would obviously be useful to be able to access the telephony functions remotely. Of course, there are various ways of sending SMS or placing voice calls from a computer without a pinephone. Most if not all USB cellular network dongles can send SMS, and although voice capability is not universal, suitable dongles exist. However, this requires either a separate SIM, almost certainly on a different account with a different telephone number, or swapping one SIM between devices, which is far from ideal. I want to use my regular cellphone for this, and the pinephone should be capable.
I decided to tackle SMS first. As I mentioned above, the default SMS application in KDE plasma mobile is spacebar, and incoming SMS messages received by the modem are processed by spacebar and entered into a sqlite database. I don't want to change that behaviour, because I want to be able to pick up the handset at a moment's notice and use it independently of a computer. Accessing inbound SMS via an ssh session is intended to be an additional option, and also a way to archive old messages on a real computer with all of my other work, deleting them from the handset.
Copying the SMS message database via sftp was trivial, as was writing a script to dump the contents to a textfile. However, when I invoked spacebar from the commandline, expecting to see an option such as --send-sms, I was out of luck. Nope, this is strictly a gui program and the usage summary lists no command line option to send an SMS.
I decided to check the manual page, and to my astonishment, found that no manual pages were installed by default. Even more bizarre is the fact that although vim is installed as a vi-like editor, it's not symlinked to vi. So here we have a unix-like environment with, by default, no manual pages and no vi. Maybe it's just me, but this doesn't seem like a system designed by serious Linux enthusiasts. A package of manual pages is, of course, easily installed, but even then quality was variable.
“No manual pages were installed by default and typing vi didn't invoke an editor”
In any case, the option to send SMS from the commandline wasn't there, and although I could use a lower level approach, sending messages directly with at commands over the serial link, I'd then have to add them directly to the sqlite database if I wanted them to show up in spacebar. It worked, but seemed like too much of a hack, so I moved on to voice calls.
The goal here, was to relay the inbound and outbound audio from a voice call to a sndio server on the OpenBSD machine. In case you're unfamiliar with sndio, it's the default sound server on OpenBSD, just as pulseaudio is the default sound server in many or most Linux distributions.
Audio routing is obviously going to be non-trivial on a telephone. On a desktop workstation used for VoIP calls, for example, you most likely have a single soundcard with a single mono microphone input and stereo speakers. Audio goes in through the microphone, and out through the speakers, nice and simple. A phone, on the other hand, typically has multiple sound devices.
There is an earpiece for regular in-call audio, and a loudspeaker for calls on speakerphone, as well as audio such as ringing, alarms, and music playback. In addition, the modem may also have digital sound inputs and outputs. With analogue PSTN voice/fax/data modems, the audio data for PSTN calls could usually be sent as raw PCM data over the serial link after entering a specific AT command setting the modem up to receive it, but the modem usually also had other audio inputs and outputs. It's a similar situation with cellular modems, and the more devices you have, the more interconnections there can be between them, making the mixer controls quite complicated and un-intuitive.
As a first step, I tried simply recording voice call audio, with no success. It was easy to identify the streams that seemed like they should contain the audio data, but although microphone audio was successfully recorded, I was only able to capture digital silence from the earpiece monitor stream. I noted with interest that ending a call in the phone dialer application whilst holding the audio stream open with another program, resulted in the dialer not registering the fact that the call had ended.
Crystal tip:
Call encryption?
In case you're wondering if it would be possible to encrypt regular voice calls, the answer is yes, but it's complicated by the fact that the modem doesn't, (as far as I'm aware, with the firmware currently available), expose the raw voice call bitstream that it receives from the cellular network.
So if you handled audio capture in software, you could probably do some simple scrambling such as frequency inversion, then send that audio back out to the modem as PCM data, but you couldn't do bit-level encryption of the compressed data. Audio quality would likely be poor, as the compression codecs are likely not optimised for this kind of audio. A voice changer, on the other hand, for privacy purposes, might be more feasible.
At this point, I'd seen enough bugs that I was beginning to lose interest in trying to work with the telephony functions as implemented by KDE plasma mobile. For what I was trying to do, it just seemed to be getting in the way of the raw hardware and lower level interfaces. I'm also curious as to what is gained by using ofono as part of the telephony stack instead of the more commonly used Modem Manager.
Instead, I turned my attention to VoIP. Clearly, a VoIP client would be a useful thing to have on a cellphone.
VoIP on the pinephone
Once again, I seem to be on my own doing this. Although there is certainly no VoIP software included by default, I at least expected to find developers talking about it, but various searches on-line didn't turn up anything of interest.
Undeterred, I copied the source code for pjproject 2.9 to the pinephone, which is about 4.8 Mb compressed, and installed a few dependencies for the build process via binary packages.
The default compile options won't work correctly on the pinephone, as the compile will try to include a header file for SSE instructions, which obviously doesn't exist on the arm architecture. The --disable-libwebrtc option avoids that dependency, and I also disabled video support with --disable-openh264 and --disable-video, because I'm only interested in audio calls.
After about 15 minutes of compiling, the resulting binary appeared to run, but live audio during calls was badly distorted to the point of being unusable. Infact, it had all of the characteristic sounds of being byte-swapped. The recording of the call was much clearer, and deliberately byte-swapping it produced audio that sounded exactly like what I was hearing during the live call.
Conclusions
After two days of playing around with the pinephone, other work was beginning to build up, so I decided to stop here, and draw some conclusions. What I really want to do is to install a BSD system on it, but that almost certainly means setting up a serial terminal, and a lot of low-level debugging, so it won't happen anytime soon.
Update - 20210525
OK, despite being busy with other projects, I decided to have a quick look and see if anything had changed with the pinephone after three months, with the latest software updates.
“There have been some welcome bugfixes, but overall not much has changed”
Some things have definitely improved, and there have been some welcome bugfixes. USSD codes are now implemented, but when I tested one that returns a menu with further choices, I wasn't able to select an option from that menu, so there is still work to be done here. Cellular data now seems to stay switched off over a reboot, which is very welcome if you want to keep it switched off to avoid data charges.
However, the bug with sending and receiving emoji in spacebar hasn't been fixed. The phone dialer still doesn't end calls correctly if the pulseaudio stream is held open. Many of the GUI bugs are still there. Not a great deal has really changed.
“I did get VoIP working, though, and audio quality was excellent”
I did succeed in getting pjproject working, though. Something seems to have changed with the audio configuration, as it no longer sounded byte-swapped, but distorted in some other way. However, adding --stereo to the configuration file, and opening the sound device in stereo mode completely fixed all audio problems, and made VoIP usable on the pinephone.
Some manual tweaking to audio levels was necessary, as the microphone recording level was very low by default, but it does work. I made several test calls from the Pinephone, using cellular data for the internet access, and the incoming audio quality was excellent.
Oh, and one side-note. Is it really too much to ask that the release tarballs of the OS are signed? They used to be, but now it seems that we're expected to confide in that fact that we're downloading them via https with a valid certificate. That doesn't provide the same end-to-end assurance as a signature created on the development machine.
Final update - 20210610
As I know that I'm not going to have time to sit down with the Pinephone and look at getting a BSD system booting on it, I decided to test postmarketOS with sxmo. For those of you who are not familiar with it, sxmo is a mobile user interface based mostly on text and menus, that is quite different to mainstream smartphone guis. PostmarketOS is also quite a nice Linux distribution for those of us who are more familiar with BSD systems.
First impressions? It's excellent! A full write-up might come at some point if and only if can actually put the Pinephone down for long enough to write one!
So what do I think after two days using the pinephone?
“The hardware is nice, but the software just isn't there yet. My biggest concern is that maybe it never will be.”
Well, for a start, the hardware is nice, very nice. Do bear in mind that I've only physically tested one unit, so I can only comment and draw any conclusions regarding the build quality of my particular handset, but this one is certainly well made.
The specifications are enough to get useful work done, and what's more, this device is available to purchase today.
You too can own a pocket-sized, portable Linux device in 2021. Two years ago, that was much more difficult.
Unfortunately, just about every other aspect of the pinephone was a bit of a disappointment to me. The software just isn't there yet, and my biggest concern is that it might never really get there. The fact that such obvious bugs in the core SMS application and phone dialer applications have, seemingly, gone un-noticed suggests to me that few developers are actually using this device as a phone.
If certain functionality of a piece of software isn't tested, then the code often rots, and bugs will likely creep in to supposedly stable future releases. We've seen far too much of this lack of stability already with mainstream smartphone systems, isn't this exactly something that an opensource, community developed project would really like to avoid?
Whist there seems to be a lot of enthusiasm for adding glitzy features, nobody seems to care passionately about tidying up the details and making the overall experience of using the software a sleek and polished one. There is still no actual installer, for example, so re-installing the system means writing an image to the eMMC.
From a technical point of view, the system seems to be built out of far too many software layers to promote reliability. The phone dialer bug that prevents calls being ended whilst the corresponding pulse audio stream is kept open, suggests to me that little thought has gone in to how the high level code is supposed to propperly receive and handle errors passed from the lower layers of the telephony stack.
“Why do we use the system login password on the lockscren, instead of a separate PIN?”
I also can't understand the reasoning behind using the user's system password as the pin for the lockscreen, which then means that it has to be restricted to digits only.
This is the same password you use for ssh access, unless you are using a key and have disabled password authentication, so it should be a strong password.
There are two aspects to this, firstly why does the lockscreen display a numeric keypad instead of a full keyboard, which would allow an alphanumeric password to be entered? Secondly, why does the lockscreen use the system password at all? It's not actually logging you in, that's done automatically on boot. When the phone displays the lockscreen, the user is still logged in. Why not just have a lockscreen pin that is completely separate to your system password?
Many of the gui controls just seem to be front-ends to other programs. For example, the wifi and cellular data icons just seem to toggle the various configuration knobs of network manager. Is this really the best approach for what is effectively an embedded device such as a phone, or would it be better to cut out some of the layers and have the gui control the built in devices directly at a lower level? Using the pinephone as a smartphone, does the user want or need the full flexibility that network manager provides, or does it just get in the way if the phone is only going to be used in one or two fixed configurations?
Admittedly, this is an open question, because it depends on the user and what they are doing, but it's not even clear, at least to me, who the intended userbase for KDE plasma mobile is, either. If the system is intended to appeal regular smartphone users, then it would need to be optimised for different use-cases than if it's intended to appear to power users. If it's intended to appeal to both, then it will take some careful thought to optimise it in such a way to give a good experience across the board.
Some things just seem to be over-engineered. The calculator application includes a unit converter, but instead of just the regular four or five conversions that you might expect to find, opening it presents an absolutely huge list of conversions. Whilst this was amusing, I'm not overly convinced of it's usefulness, because if you work in a field where you need to do an unusual units conversion, you likely already know the formula anyway. It just seems like over-engineering for the sake of it, with little practical gain.
A similar issue is present in the sound recording application. It lists a bewildering array of file formats and container formats, many of which don't even work. Why? Why not just record to a pcm file, or lossless flac with a light compression setting for low cpu usage, then let the user convert the file afterwards? If the user wants to set up something complicated, then presumably they know what they are doing, and either do it from the shell or install a program of their choice.
“Why not make the telephone side of the device simple like a featurephone, for increased usability on the move?”
I think the point here is that I would prefer the default bundled KDE applications that provide the basic core functionality of the system, to stick to the point, and provide a slick, snappy, interface to those functions. If I'm in the office and I want to record some audio on the pinephone, sure, I might appreciate a selection of formats. If I'm out and about and I pull the phone out of my pocket to record a memo on the go, I just want it to start recording immediately in raw pcm, and I'll compress it to whatever I need to later on.
Think about it, a mainstream smartphone as such is a compromise, trying to offer computer-like facilities in a cellphone form factor, with a smartphone-specific operating system. With the pinephone running KDE plasma mobile, or any other gui on top of a mainstream Linux distribution, we don't need to compromise. We can have the full power of a desktop Linux installation whenever and wherever we need it, so why not make the telephone face of the device simple like a featurephone, for increased usability on the move? Of course, this could all be configurable, so nobody really loses out.
Ironically, a lot seems to be being done to support every possible unusual configuration, but most if not all of the developers seem to be using this device in the same bog-standard way, with no SIM card and internet access over wifi.
My final disappointment was being unable to find a single central resource, preferably a mailing list, with serious technical discussion of pinephone software development. Any serious low-level development discussions about this device and it's software, seem to be spread out across various different platforms, forum posts, blog posts, social networks, and the occasional developer website. It's clear from the forum posts that a lot of these handsets are making their way into the hands of people with little or no Linux development experience, and it quickly became tedious searching for technical discussions amoungst posts about trying different distributions to see what works, complaints that the screen broke when the phone was dropped on the ground, and questions about delivery that have already been answered repeatedly in other places.
So overall my final thoughts about the pinephone are simple: It's great, but it could be so much better.
Nice hardware, but there's still a very long way to go