Go A12 (and then also the aforementioned A12 v2a blobs), which is the combination that’s been working for me flawlessly for 1,5 years, whereas A13 base was tested by me only a couple of months. And even thought I didn’t experience any issues with it myself, it was A13 base (and never A12) that several other people reported here and there as having occasional in-call echo with it.
And if you have A12 firmware readily available for direct flashing via Emma without all that additional hassle (in my case it took hours of manual A11→A12 updates via OTA, involving bootloader relocking and unlocking), then I wouldn’t hesitate a single second.
Thanks, but perhaps you skipped over the remaining (long) story, since A12 + v2a is exactly what I continued to describe doing.
Any thoughts on this part?
Additional discovery today: in a pitch black dark room, green blobs seem to disappear if you specifically max out “Settings > Display brightness base level” slider. I say “seem to”, because maybe they become so faint, it’s near-invisible with naked eye? Regardless, anything below max === app Home view cards generate clearly visible green tinted blobs below app icon grids. On A12 base + v2a blobs.
Another “partition restore” note: ofono wasn’t able to complete mobile data connection with ERROR: GDBus.Error:org.ofono.Error.Failed: Operation failed until fortunately Resetting oFono Settings | Sailfish OS Documentation emptying /var/lib/ofono seems to have worked!
I must confess that you’re right, I only read the last question Well, if you get some undesired effects on that combination, then, obviously, you might want to try something else… I really don’t know if it is device specific, or maybe my perception level is different, but I really do not get any display or echo problems on A12 + v2a, and that’s the reason why I recommend it. But maybe it’s true - like someone suggested some time ago - that two different display types/models were used in different 10 III batches. If so, and we have different displays, then your mileage may vary….
I can tell you my take since I tried all possible base and blobs combos.
Not only nothing helps ultimately, but the green hue/smearing whatever it’s called doesn’t even go away now with the brightness fix script (I think I left it with 12+12 as I gave up).
There’s definitely different points where the smudges appear and different scale depending on the base + blobs combo, but the only thing that works is 11+11+ brightness fix script.
What-ho sailors! I just installed Sailfish OS on my Xperia 10 III with all the latest Xperia software and Android 13 updates installed on it. Didn’t revert back to earlier Android versions as was suggested by the official installation instructions.
After flashing SFOS and booting first time, everything seems to be working so far. This is my first time flashing and using SFOS so proceed with these files at your own risk. I installed OP-mobiili, Volvo Cars and Olvid from Aurora Store to quickly test if they work out of the box, but OP complains about incompatible phone and Google Play services (there’s a workaround I haven’t tested yet) and attempt to sign in to Volvo Cars app with my Volvo ID returns with a “permission denied” error, after giving my credentials on redirected Jolla browser.
I will be replacing my Fairphone 6 /e/os with this SFOS Sony Xperia III as my daily driver, if I manage to get these apps working. Had to cancel J2 because of the size of the phone which I can’t use one handed (it’s my main gripe with FP6 too). Xperia III fits my hand far better in this regard.
Hello and welcome! At least OP works for sure. I don’t know if it need MicroG or not as I have MicroG enabled. But the command line workaround is needed for that. Hopefully you have smooth sailing
Final update: tested Android 13 + matching Android 13 binary — same VREG_NG error, 100% reproducible
Following up on the suggestion to try Android 13 with the matching binary (thanks @tn71 and reference to @wetab73’s success story):
Setup: Android 13 (62.2.A.0.525) via Emma + Sailfish X 5.1.0.11 + SW_binaries_for_Xperia_Android_13_4.19_v2_lena.img (same binary version referenced in the successful report)
Result: Same failure pattern. Screen shows Sailfish logo, dims, and backlight responds to touch/power button — but no UI ever loads behind it. Pulled the full persistent journal this time and got a much clearer picture: every single panel power-on attempt triggers VREG_NG, with no exceptions:
14:38:32 panel power on → VREG_NG interrupt!
14:39:31 panel power off
14:44:24 panel power on → VREG_NG interrupt! (after a power-button wake attempt)
14:44:58 panel power off
14:47:40 panel power on → VREG_NG interrupt!
14:48:14 panel power off
14:48:36 panel power on → VREG_NG interrupt!
14:49:10 panel power off
14:49:59 panel power on → VREG_NG interrupt!
14:50:33 panel power off
5 separate power-on attempts across a ~12 minute window, 5/5 VREG_NG faults. This appears fully deterministic, not intermittent.
Summary of everything ruled out at this point:
Wrong/corrupted binary (MD5-verified against md5.lst every time)
Android 11 vs 12 vs 13 firmware base
Matching vs mismatched binary/firmware Android version
Since the screen works perfectly under stock Android on this exact unit regardless of Android version, but fails 100% of the time under the hybris/Sailfish kernel across every combination tested, I’m now fairly confident this is either:
A genuine marginal hardware fault on this specific panel’s power circuit, only exposed by the Sailfish kernel’s particular power-sequencing timing (and tolerated/avoided by Android’s different timing), or
Something in the shared hybris panel driver code itself that’s incompatible with this panel revision/batch, independent of which AOSP base or binary blob version is used
Given the unit was purchased used, option 1 seems plausible. I’ll be pausing further testing here and looking into hardware repair options. Many thanks to everyone who contributed ideas — this was a genuinely difficult one to pin down, and the journal-log approach suggested earlier was key to getting concrete data instead of guesswork. Leaving this thread open in case anyone recognizes the exact fault pattern or has other ideas, but not expecting to actively continue testing for now.