Dialing works too now! It was a bit more involved than I expected, because I
had to go and rework input-method/text-input support in swc to be more usable.
This was necessary so we could use svkbd as the dialing pad.
Specifically, swc now launches and kills instances of input methods as
necessary. As part of the text-input protocol, a program can provide
a purpose for which the input is required. swc uses this information to
launch the right input method. For example, the dialer uses the phone
purpose, so swc knows to launch the dialer. When the client program deactivates
a text input, the input method is killed.
Dialing was working well by Tuesday of this week, so to celebrate the fact that
my Pinephone could now receive and dial calls, I decided to go back, and build
a system image from source. As a reminder, I based the image that I was using
up until this week on postmarketOS, and replaced the rootfs, kernel and device
tree. The only thing that I hadn't built from source was u-boot, ARM Trusted
Firmware, and Crust. Luckily, Crust provides a Makefile based build system to
build this by changing a few things in the Makefile and running make. Unluckily,
the phone seemed not to detect the SD card. After inquiring on #linux-sunxi, it
turned out an entry in the u-boot device tree was missing, causing the SD card
not to be detected as mmc0 as it should have been. After adding a line to the
device tree, it booted flawlessly. I now have an SD card running my oasis system,
built completely from source.
And now you can too! I spent some time this week cleaning up my oasis repo, and actually commiting things to history. I have uploaded it to this website, here.
Finally, given that the project has been progressing for over a month, I thought it would be a good idea see how my progress compares to the original objectives:
The AT command daemon's protocol and basic internal workings have most likely been
finalized. It is able to submit AT commands to the modem, keep track of incoming
commands in a queue, and hand off URCs to appropriate handlers. calld falls under
this umbrella as well, because it handles integrating calls with the rest of the
system, a task that I had not forseen a need for when I first started. SMS support
is still missing.
I originally thought that I would implement the virtual-keyboard protocol, but I
ended up choosing input-method as it is ironically more suitable for a virtual
keyboard. This past week, I implemented what should be the final model of
input-method support in swc, where the compositor manages input methods based
on text-input protocol requests from clients. While some tweaking/bug fixes may
be necessary, I don't see this model being changed.
svkbd is mostly ported, but it's missing support for overlays and long presses.
I'll add support when it becomes more pressing.
swc supports touch, but there may still be bugs and some semantics that
need to be tweaked.
I wrote last week about a pretty small compositor that I wrote just as a starting
point. Well I have now named it mowc
(for mobile wayland compositor). It still is far from a complete mobile Wayland
compositor. Some obvious things that are missing are an app launcher, a status bar,
and a way to perform compositor actions using the touch interface.
There is a dialer and programs to deal with incoming/active calls. Their interfaces are still missing features like volume/source adjustment. Also there needs to be an SMS program.
Given that most of this stuff is mostly done, I think it is appropriate to define a new set of objectives:
Unless I'm missing something, the support for the above will be sufficient for me to switch to the Pinephone as my daily driver.