This week I wrote an smsd which talks to atd and simply
writes incoming texts to a file, whose name is the number of the sender.
At this point, besides fleshing out SMS, the only thing left for a usable system is reasonable power management. When carrying a phone around, there are certain expectations that you have in this regard:
It should be able to detect when the power button is accidentally pressed, and turn the screen off in a reasonable amount of time. This is vital, as large amounts of power can be burned if the the power button is accidentally pressed when the phone is sitting in a pocket or a bag, and the screen is left on without the user noticing. From testing, this happens more than one might think, and we simply don't notice because our phones are so good at dealing with this.
The screen should time out after a certain amount of time without input. If a phone is placed on a table with the screen on, it obviously shouldn't stay on forever, especially when on battery.
There are a few exceptions to these rules:
If in a phone call, we obviously don't want the phone to go to sleep and terminate the call. It might be acceptable to turn of the screen however.
If there is work to be done, such as a URC that must be processed or commands in the modem queue, the phone should not go to sleep. Again, the screen should just be turned off and not accept input in this case.
So it appears that there are two distinct types of sleep that must be handled:
a "shallow sleep", where the screen is off and doesn't accept input in order to save battery and prevent spurious, unintended inputs from happening. The phone still has processing to do, so it remains awake.
a "deep sleep", where the rest of the phone is also in a reduced power state, and doesn't wake up unless a phone call or SMS message comes in, or the user can just wake it up using the power button. This can just use crust.
To help implement this behavior, I wrote a program called sleepd. sleepd
decides when the phone should go to into either type of sleep. All programs that
need to deal with sleep will have to talk to it. sleepd exposes a unix socket
interface, over which it can be sent commands. A program can send a request to
"lock" the phone awake (shallow or deep), unlock it, or set a timeout to a
shallow sleep. If a program is in a shallow sleep, and no deep sleep locks are
present, the phone will automatically go into a deep sleep. The next step is
testing and integrating it with the rest of the system.
Regardless of my progress this week, next Sunday I will post the final installment of this series as my summer break comes to an end. Next week, I will also put up a webpage for the project and give it a proper name, because I think it's almost theoretically functional enough to use. I'd like to show off what it is currently capable of, and see if other people are interested in helping develop the system further.
Speaking of, if you are interested in helping me develop this system further and have a Pinephone, please send me an email! There are many trivial features that are missing in both the telephony stack and GUI system, and likely many trivial bugs that can easily be found and squashed as well.