The software on Linux phones is too big for my taste.
In terms of UIs, Sxmo, a phone interface built on suckless programs, is the smallest that I have found. The Xorg server is pretty big, so something Wayland based could get much smaller.
Another thing to consider is the telephony stack. Both ofono and ModemManager, the two most widely used telephony stacks, are around 200K SLOC each, and depend on dbus and glib. For a simple phone system, this is undesirable.
Lucky for us, a simple Linux system already exists: oasis. It has a lot of unique features that make it well suited for a phone system. For example, you can build the root file system on a desktop, push it to a git repo, and update the phone by pulling from that repo. This is what I will base the system on, and in fact, it provides most of what we need. It is missing a few things however.
The window manager for this system, velox, is built on a library called swc, which implements a small Wayland compositor. swc is missing two key features for a phone system: touch support, and virtual keyboard protocol support. Velox is not really meant to be used as a mobile compositor, so I will make one that is.
Speaking of virtual keyboards, we need one of those too. I couldn't find a small virtual keyboard for Wayland, so the best option is probably to port svkbd from X.
For the purposes of a simple phone system, the AT interface to the modem should suffice. Generally, the AT interface is command based: you send it a command, and it responds with a result code when it's done. So it would be reasonable to wonder why we can't just have these clients send commands directly to the modem. It turns out that occasionally, the modem sends things over the AT interface that are not responses to a command. These are called Unsolicited Result Codes (URCs). Their main use is to let the system know when there is an incoming call or text. I think the simplest way to do this is to have a daemon that listens for and handles these URCs, and also queues commands on behalf of multiple clients. I will have to make this too because as far I'm aware, there's nothing like this that exists. The commands are pretty well documented, but some specifics about how URCs interact with incoming commands and data mode are not, so this will required some experimentation to get right.
To top everything off, we will need some apps to access the telephony functionality. I have some ideas for how I want to approach this, but functional parts are the priority for now.
Here is an overview of what needs to be done:
By the end of the summer, I intend to have a Pinephone system functional enough to use as my daily driver, and simple enough that the userspace can be understood in its entirety, without much effort. I will post weekly updates on my progress.