Sony Nagara (Xperia 1IV and 5IV) port

Devices
362

I am pretty sure that I have used the formula to determine pixel_ratio as set in droid-config-sony-nagara/rpm/droid-config-xqct54.spec at main · sailfishos-sony-nagara/droid-config-sony-nagara · GitHub.

Now, if you want to check, please look up the recommended formula for it in SFOS porters docs or some forum post (I don’t remember where it was) and check if the value is correct.

Taking into account there are some issues with the browser, I wonder if you restored something from backups when migrating to Nagara? If you did, try to make a clean start - maybe some configs got messed up.

1 Like
363

Apparently there’s a “Treat mobile data as WLAN” in AAS now: [Release notes] Tampella 5.0.0.73 - Early Access - #120 by Keto

Has anyone been able to test this with this port yet?

I will only be able to do that tomorrow.

2 Likes
364

No, I have not used any backups, literally everything was either set up from scratch, or manually imported from .vcf (contacts), .ics (calendar), and so on. I did not restore any data in the browser, either, and the issue with it was there right from the beginning (browser was the very first thing I’ve checked and the first keyword I typed already didn’t work).

Yes, that’s probably the best thing to do. Especially that now I also have a problem with icons of Android apps not getting - something got broken when I tried to manually update AAS on the 1 IV to the latest version by reinstalling the changed packages (only a handful of them were changed) taken from the 10 V. Strangely, the very same problem appeared on the 10 V itself, where the update was normally applied (GUI OTA).

I’ll start from scratch and see if it fixes the browser issue. What is the best way to do it? Reflash Lineage recovery, from there format the partition, upload and unpack the SFOS archive once again, reflash SFOS boot? Is it better to use version .68 of SFOS image and then update the system to .71, or go the .71 (testing) image directly?

Well, I’m sure that it’s correct, and I am not complaining. It’s just too huge for my liking, so I am trying to find an (easy) was to make it smaller a bit. I would very much like the UI to retain the same proportions of its elements and the same amount of data as on other models (where IMO it is optimal), especially that the bigger display itself already makes things bigger, so it doesn’t really need to be additionally boosted even more.

I guess that the above screenshots speak for themselves - see how only 6 contacts fit on the list on 1 IV screen vs. 12 contacts on 10 III display. It is twice less. Same for thumbnails - those on 1 IV screen are literally 4 times bigger. Is there a logical explanation for this? I mean, even if the formula and the resulting value is correct per se, does it really give desired effect? If not, is there any way to modify it on a live system rather than when building it?

Thank you very much for all the information and help, and kudos to you for your great work!

365

I am not - so independent test would never hurt

1 Like
366

That’s what I wanted to test - that was the reason why I tried to update (correctly working) AAS to this latest version taken from just updated 10 V, by updating only the modified AAS packages. But I ended up with AAS restarting in a loop on the 1 IV so maybe it needs some other OS (not strictly AAS) packages provided by the .73 update. I will try again with a fresh SFOS installation.

367

Of course, I will check it.

368

@rinigus One quick remark: when calculating the pixel_ratio value, did you take into consideration that even though the 1 IV screen’s hardware resolution is 1644 x 3840, it is actually very rarely used (and probably only on Sony’s stock Android) and most of the time (and probably all the time in SFOS) much lower resolution of 1096 x 2560 is in use, which is almost identical to the one in e.g. 10 III? Does the current value match the higher (unused in SFOS), or the lower resolution?

369

I did it in Nov 2024 => don’t remember

370

OK, I will try to check it myself. But something tells me that’s the reason. The screen resolution given by Sony in specifications is misleading as the 1644x3840 resolution is rarely used even in their Android (almost exclusively for playback of hi-res videos, for camera viewfinder in their apps, and a few more such specific uses). Please see e.g. here. In real life usage, using the lower resolution effectively reduces the UI density to just 420 dpi and not 643 dpi as they advertise it, so the commonly used pixel density is actually even lower (rather than much higher) than on the 10 III, 10 V or 5 IV.

Therefore, pixel_ratio value of 1.75 should be used on SFOS, where the higher display resolution is currently not used AT ALL. Unless you are planning to enable it in this port, that is….

P.S. On earlier SFOS versions UI pixel ratio could have been easily changed by the user via dconf:

dconf write /desktop/sailfish/silica/theme_pixel_ratio VALUE

but it turns out that recently they made this value read only :frowning:

371

OK, so I’ve checked it, and the pixel ratio value (out of those default ones) corresponding with 1096x2560 resolution and 420 dpi density should be 1.75.

So 1.75 value should be used for this resolution and density (which are the ones used by your port) rather than 2.0. Alternatively, the resolution should (somehow) be changed to 1644x3840 (if it makes any sense, as even Sony use it only for a few specific cases and they say that it eats more energy) which would boost the dpi to 643, and only in such case it would match the currently used pixel_ratio value of 2.0.

EDIT: OK, so while this should be configured by the port author, I was able to find a post-build workaround: make the dconf key writable and modify it from 2.0 pixel ratio to 1.75. It results in the UI looking exactly as on all the remaining devices, with correct sizes and proportions. What you need to do (as root) is the following:

  • edit /etc/dconf/db/vendor.d/locks/silica-configs.txt and put # sign in front of both lines contained in that file (which will “comment” those lines i.e. disable them) to unlock those keys and make them writable
  • then issue dconf update to update the database
  • finally: dconf write /desktop/sailfish/silica/theme_pixel_ratio “1.75”
  • restart Lipstick
  • enjoy correct pixel ratio resulting in correct UI item sizes and a lot more content visible

The second key (/desktop/sailfish/silica/theme_icon_subdir) should probably also be modified from “z2.0” to “z1.75” but for now I somehow can’t modify it. Icon sizes seem to be correct even without modifying that second key, anyway.

4 Likes
372

Sadly, it clearly isn’t there. Jolla just said that it’s not present on either 10 II or 10 III, plus I cannot find it on my 10 V, either. So there aren’t much device models left to choose from, right? See

Edit: it ended up being enabled on C2 only :confused:

373

Hmm, I have a C2 too, will check.

EDIT: Yeah, there is such an option there, but it will probably require the oFono changes in the OS update, which we currently don’t have.

EDIT2: I have force shown the switch in settings, but still doesn’t work. :person_shrugging:

1 Like
374

Maybe just replacing ofono-binder-plugin from the c2 would be enough? :wink:

1 Like
375

Well, no, I’ve thought about that, but that plugin is not used in the C2 adaptation. It gets replaced by the droid-configs of the device (which seems to feature some AAS configuration, but I need to investigate more).

2 Likes
376

Today when I switched the 1 IV on, it started with ambience changed to the default “5” one. Yesterday the device was normally shut down with the Water ambience (it still isn’t my primary phone, so I switch it off for nights). This is the second time such a thing happened - I don’t know if I should treat it as unique problem of my own device or if I should report it as an issue.

The browser search function problem persists. Also in this case, I don’t know if it is my unique problem or a general one as no one else responded. Does anyone else have it on either the 1 IV or 5 IV? If not, I think I’ll go with a fresh SFOS install, so I would be very grateful if someone could confirm.

As reported earlier, the pixel ratio value in the 1 IV port is incorrect and should be changed from 2.0 to 1.75. That’s because the port uses 1096x2560 resolution rather than 1644x3840. Should I submit it as an issue on the port’s GitHub so that it could be corrected in the next release?

As posted by @bundyo earlier in this thread, certain kernel config options (mostly networking related) are currently missing (he posted a list). Is there a chance to have them included, which - hopefully - might address AAS not recognizing mobile data?

2 Likes
377

I’m also not yet using the 1 IV as main phone because of the mobile data issue so sorry for not reacting.

“pizza” takes me to a Google results page, but no matter what I set my search engine to: it takes me to a Google results page.

edit: I forgot to add: with my aging eyes I love the current DPI

2 Likes
378

Thank you for checking. Where was the formula?

1 Like
379

on my 5mk4 search in browser works ok.
changing from google to yandex in settings also works correctly

1 Like
380

On my 5mk4 browser works as well as expected. In general I have to say this port is one of the best experiences I ever had with a Sailfish port. Only thing which is sometimes a bit nagging is the fact, that just one fingerprint is working. But that’s for sure complaining on a very high level.

1 Like
381

would be good if somebody who knows told us how to manually edit the file with fingerprints, adding the one from another finger.