Xperia Tama port: discussion on future direction

Devices
#1

I am opening a separate thread to start a discussion regarding next steps of Tama port. I would like to start with the thanks to all who took time and tested AOSP10/aarch64 SFOS port and helped with the feedback. In addition, the port was made possible due to the help of fellow porters. The feedback of Sony AOSP team is very much appreciated as well.

State of AOSP10/aarch64 based port for Tama is far from the best. We have several issues that are originated from AOSP10 and the used blobs with the latter being suspected for the main ones. Here I will give a short overview of the issues and try to compare the state of the port to the one we have used earlier - based on AOSP9/arm32 SFOS.

Issues

Battery

There is a significantly larger power drain in AOSP10. When tested on the same device in flight mode, drain is jumping to 0.9%/h (AOSP10) from 0.25%/h (AOSP9). Such jump has been observed in AOSP10 without SFOS as well. In general, it does feel that the drain is larger than before when you use the device as a daily driver as well. In part, it can be mitigated by a small governor switching off power hungry CPUs making it possible with my usage to get just below 3%/h during a day. What is causing the drain I don’t know, it is possible that something is off with the BLOBs as well. Issue: Power consumption while idling · Issue #154 · sailfishos-sony-tama/main · GitHub

GPU

When showing just Lipstick, there is frequently a choppiness in transitions. In addition, on XZ3 there are either glitches in form of lines (video Power consumption while idling · Issue #154 · sailfishos-sony-tama/main · GitHub) or some spectacular pixelation (Xperia Tama port: AOSP10/aarch64 release - #15 by Pasik2). So far, within apps there are no such problems and it could relate to singlesurface rendering issue mentioned by AOSP developers. Issues with GPU are attributed to kernel 4.14 and BLOBs. At least transitions and XZ3 line glitches can be sorted out by bumping GPU minimal frequency, not sure about pixelation. That may increase the power consumption, although it hasn’t been tested. Issues: Frame rate low for compositor on idle · Issue #143 · sailfishos-sony-tama/main · GitHub and hybris-10 XZ3 glitch on screen while swiping or unlocking · Issue #150 · sailfishos-sony-tama/main · GitHub

Wireless charging

On XZ2, wireless charging looks to be mostly gone - works very rarely (less than once in 10 times probably).

Other niggles

There is some oddity with LED (doesn’t always blink for new email notification unless it is on charger; seems to be SFOS issue noticed for Xperia 10II as well), VP9 videos don’t always resume after going in/out of browser, screen goes to max brightness for a moment when you switch it on. Few niggles were solved by patching AOSP10 (act dead mode, echo during calls), so those are resolved for SFOS. Current list of issues for AOSP10 based port are marked by a separate label in the issue tracker.

Flatpak

While Flatpak has been compiled for aarch64 and the apps can run, this is without any hardware acceleration. I didn’t manage to make hardware acceleration work on AOSP10/aarch64 SFOS base after spending some time trying to do it. It is probably possible, but would require a fresh look by someone. In general, Flatpak on AOSP9/arm32 is a mixed bag - it is working, but current Flatpak platforms don’t support this arch anymore. So, we don’t have much apps available for arm32 either.

Camera

Camera is usable on AOSP10 based port. It doesn’t crash, with the Advanced Camera performance has been better than with the one bundled with SFOS by default. For me, manual focusing mode with Advanced Camera works the best. Still, camera flash on AOSP10 based port is not in sync with photo taking. So, using flash is no go on AOSP.

See better summary from others: Camera issues · Issue #153 · sailfishos-sony-tama/main · GitHub

Future

As the port is not ideal and has significant shortcomings compared to AOSP9/arm32, we would have to discuss what to do and which solution to choose. I would not expect any BLOBs updates for AOSP10 anymore as development has shifted to AOSP11. So, the state would probably be as it is now with the hardware support.

We have several options:

  1. Stick with AOSP9/arm32 port. Main disadvantages are absence of camera and Flatpak support doesn’t probably matter soon as arm32 is phased out.

  2. Switch to AOSP10/aarch64. Will get better camera, no Flatpak support and I cannot promise that it will come. Several bugs rooted into AOSP10/BLOBs combo.

Those solutions are available now.

In principle, it is possible to develop new ports:

  1. Switch AOSP9 to aarch64. I would expect it to be way less effort than it was to make AOSP10/aarch64 based one, which took months. Main advantage is that probably (notice that it is not 100% sure), Flatpak will work with HW acceleration.

  2. Make a port based on LineageOS 17.1 which, in turn, runs on top of stock android. So, camera is expected to be better than AOSP10/aarch64. Issue with LineageOS is that they already switch to Android 11, Android 10 builds are disappearing from the servers. XZ3 is not officially supported by LOS 17.1, only 18 (but this cannot be used for SFOS yet). It is again a lot of work to make it happen and I would not be able to rely on Sony official BLOBs as AOSP-based solutions can. Flashing would be more difficult. Quality of LOS 17.1 is unknown to me, mainly tested that it is possible to get it running but proper testing will be needed first. Flashing LOS turned out to be mixed bag for me with the official instructions not leading to working image. In general, I am not keen on this solution myself as it is a step away from what was done so far.

Would be great to hear opinions of others, whether you managed to test AOSP10/aarch64 port or not.

Edit 8 Jul: added camera flash out of sync in AOSP

Edit 8 Jul 2: LED blinking/non-blinking has been also noticed on Xperia 10II (Xperia Tama port: discussion on future direction - #10 by Pasik2)

5 Likes
#2

For me at least the camera not crashing and working better than aosp9 justifies the rest of the inconveniences. Ie. its a bit brutal to have to enter long tokens by hand because the camera refuses to focus on the QR code.
The power consumption doesn’t feel much worse on the xz2c. The frame drop is “annoying” but only happens on the main page and i usually use apps with the phone which are not affected.

I am ok with the aosp10 port TBH but thats only me.

1 Like
#3

@ApB: thank you for feedback. As the port selection includes compromises, we have to voice the opinions. That’s why I started the thread.

Having a working camera is nice, indeed.

#4

Regarding flatpack. At the end of the day its something Jolla has to “solve” meaning all the newer bits have to land to SFOS so its less of a hassle for you to get it up and running. So its a bit secondary. Thats the way i see it.

PS.
Another solution for the port would be to have it run on mainline > Qualcomm Snapdragon 845 Mainline / Linux · GitLab

(Joking in case its not obvious :grinning:)

#5

Flatpak is a meta-port in some sense. It doesn’t have to do much with Jolla as it was not setup by them. Hence there is nothing for Jolla to solve.

But let’s not deviate in terms of who has to solve Flatpak issues on AOSP10 - I tried and it didn’t work out - but keep it regarding Tama port.

#6

The main cause of the issues boils down to the quality of the provided blobs which also adds a dependency to a particular kernel version.

Option 1 and 3 will use the same kernel (4.9) and blobs, the camera issue will remain the same, in option 3 apps will need to be from aarch64 right? no idea if there is any compatibility with containers.

In option2 there are some issues mainly high consumption while idling, but the rest of the stuff will be similar to SFOS aarch64.

I do not know much on LOS so it’s difficult to comment for this option, some devices will not make it to that port and the result is unknown.

What about an option 5 AOSP11/aarch64 (I know I show my ignorance now) but in longer term can be an option as SFOS will have to officially support newer devices, e.g. 10 iii. Again here we have to rely on the quality of the blobs, but work for this version is still on going?

1 Like
#7

Re option 3 (AOSP9/aarch64): yes, camera will be the same as for current AOSP9/arm32 port. Flatpak will most probably work. There could be surprises, but expectation is that it will be working. As for SFOS apps, it would be the same as for other aarch64 ports (xperia 10ii, for example)

Re AOSP11/aarch64: in principle, it is possible. Tama is supported and BLOBs are published for it. As for quality, I don’t know. If it is way better than AOSP10 or 9, would make sense to switch when SFOS will support it. Which could be spring 2022. However, I suspect Tama is not the main priority for AOSP11, it is probably newer devices, such as 10iii when it will get there.

3 Likes
#8

If battery drain could be fixed, I would like to go forward with AOSP10, aarch64, (I don’t use Flatpak, and aarch64 apps are staedily being produced, plus I have pretty easily biilt the ones I want from available sources device).
LOS17 sounds interesting to me, being a widely-used and continually developed source, so maybe promising better function and stability overall, but I would hardly wish it on you to have to dive into all that, just bases on my experience with LOS Android. I don’t understand much technically, but it seems pretty complex, and I would get the sense that ot might be quite a project, like a whole new port from scratch or something. If you took it upon yourself, I would look forward to see what could come of it, and would be glad to test/donate, bit couldn’t be much more help than that. I messed around with Android for years, and remember Cyanogenmod fondly, but I haven’t touched LOS for a few years, and have found it to be relatively hard to modify.

Thanks again for your work.

#9

If battery drain could be fixed, …

Nope, it cannot much as far as I can see. So, it is as it is now with the “fix” in terms of switching off power-hungry CPUs while you don’t use display applied in the tests as described above and in the corresponding issue. So, we don’t have much more to add with this.

#10

I jumped directly from Android to AOSP 10/aarch64 SFOS port, so i don’t know AOSP9/arm32 benefits.
For me:

  • Battery “draining” is not big problem for me. It last ~2 days for my usage
  • Wireless charging = I use it rarely
  • LED blinking behaviour is same than Xperia 10II. (doesn’t allways blink for new email notification unless it is on charger)

Only disturbing thing so far is glitch on screen while swiping or unlocking. Is there any temporary fix for it?

#11

Probably not too hard for scripters to come up with something that would listen for certain kinds of usage and activate or deactivate certain cores based on that, or something …?

Maybe this guy could help - [HowTo] Enable A72 cores to make Xperia ~1.7x faster - together.jolla.com

#12

If the LED behavior is a SFOS problem and not a port one then its fine. :slightly_smiling_face:

#13

BTW - a new battery monitor app just showed up on Openrepos, and XZ2c os specifically mentioned in description. Doesn’t solve anything, but possibly helpful/interesting …
https://openrepos.net/content/lal883/usage

#14

Re LED blinking: I have been asking on IRC (porters and regular SFOS channel) and have not got a reply regarding it. Thank you for providing it - will close our port issue as it is on SFOS then.

Re glitch: try whether this will work for you:

cd /sys/class/devfreq/soc:qcom,gpubw
echo 1720 > min_freq

Have to run it as root

#15

I wrote already a small daemon for it, so we are good in this respect. There is also some extra module made by Spiiroin for MCE - will have to test that. So, there are ways to switch on/off CPU cores and they are in use already

2 Likes
#16

Thanks a lot for the efforts and wonderful work you produce!

I have a feeling that aarch64 may be the way to go, be it AOSP9 or AOSP10 base, considering Flatpak arm32 support is being concluded. That would mean either option 2 or option 3. Not quite sure if aarch64 would make the Sailfish OS experience better otherwise compared to current arm32. Would be interesting to know that from an expert.

Always nice to have a usable camera in my opinion. And hopefully could figure out ways to tweak the system to draw less power and smooth out GPU glitches, like by using zgoverner or MCE module, eventually. In any case, although the idling power consumption is comparatively higher, more real life data may be what we could look at to identify the endurance rating. If that is decent, and having much effort already put into it, I do not see why not AOSP10/aarch64.

Interesting to note that LOS 18 uses 4.9 kernel, as mentioned on the XDA thread.

1 Like
#17

OEM Android10 on XZ3 is also using kernel 4.9, which I think it’s the same kernel version used in Android9. That also implies binaries (blobs) they use do not have to change much.

#18

LOS is based on Stock - Android as given by Sony itself when it sells you the device. So, they use Stock BLOBs as well which are probably way better tuned and tested than BLOBs used for AOSP. As stock stayed on 4.9, LOS kernel is the same.

Re Flatpak/aarch64: as I don’t want to make any promises regarding Flatpak/AOSP10, assume that it is Flatpak vs Camera when comparing AOSP9 vs AOSP10. While I cannot be 100% sure, I hope that AOSP9/Flatpak/aarch64 is possible.

Re aarch64/arm32: don’t know how they stack up. I would expect on SFOS part the differences will be minimal over time (right now AOSP9/arm32 sounds to be more polished)

2 Likes
#19

This worked for me, no more glitches.

1 Like
#20

Hi @rinigus,
Thank you for this port(s) and all the SFOS things you develop!
(I wish I went for an OLED tama device instead of trying to start a port:)

I just wanted to share that at least 3 or 4 issues are visible in another port I’m working on, so they might be AOSP or SFOS middleware related after all.
My port-in-progress is actually Lineage-17.1 (unofficial) based and exhibits these three:

(I’m curiuos if you used a specific video test page to single out the codec, but I definitely need to restart the browser for videos to ever resume)

This was my conclusion too.

I have something similar.

As for the fourth one, I believe I have seen lipstick glitches too, but not something that I worried about to file a bug.

So what I am trying to say is that some of these issues may not by Sony related after all.
HTH,

–
b100dian