I think a great many people will write the same thing I am: "Why should I change anything when it has been working to my complete satisfaction over 90% of the time" 🤔
So why open a can of worms when the barrel was drained long ago 🤔😏
I think a great many people will write the same thing I am: "Why should I change anything when it has been working to my complete satisfaction over 90% of the time" 🤔
So why open a can of worms when the barrel was drained long ago 🤔😏
---
ex calipoint say: my Knowledge of today is what I read yesterday 🧐😉
Dear colleagues,
To clarify my stance: my advice was meant exclusively for @Facan. If a user is inexperienced with editing sys.txt, the best choice is to do nothing. The native 64-bit iGO engine (9.35) was coded to handle modern rendering automatically, and it is fully capable of doing so without manual forcing.
When I joined this forum, @Boki advised me to read a lot and study existing threads. He was absolutely right. Through autodidactic learning, I realized that as long as we use Mastro Pongo's original, unmodified skin files, the 64-bit engine scales things on modern high-DPI Android devices much better than outdated, forced Primo-era [rawdisplay] commands.
How do we even know a device's correct layout anyway? The 64-bit iGO engine reads the physical hardware values directly from the Android OS (DisplayMetrics / PPI) and automatically applies the correct base_dpi and internal scaling based on the device's native screen density. The same applies to resolution—modern Android handles screen orientation and dynamic scaling natively, making strings like screen_xy or manual DPI forcing completely obsolete on modern flagship devices.
Of course, "tastes differ". If someone wants to tweak parameters to match their personal aesthetic, they are free to experiment. But for an inexperienced user, forcing lines like driver="gles_2_0_android" or manual DPI settings on modern hardware is just asking for performance loss or a black screen. Leaving that section completely blank remains the best choice for a stable, hassle-free experience.
@AnthonyGreek,
Thank you for your insights! As someone who respects your work on customizing Pongo skin visuals and resizing UI elements, I have a quick developer question.
How do you think your custom layouts (like enlarged buttons) would adapt if you fully relied on the 64-bit engine's native PPI auto-scaling instead of forcing it via sys.txt? Do you think it could make your modifications even more stable across modern high-DPI displays, or would it simply break the custom proportions you worked so hard to fine-tune?
I would love to hear your thoughts on finding this balance!
Last edited by Andrey Form; 25th September 2026 at 09:29 AM.

Thank you. One difference was at the AvSpeed-Time_se.zip ux. I had to make the fonts smaller. The other I can't remember, I just remember that I didn't change anything.
Now, I again left the [rawdisplay] blank and at first glance everything is fine. As I said the difference was very small, non essential.
If I find any more differences I will upload photos though I don't think I will.
Colleague, you're mostly right.
However, precisely on modern devices/ screens that have abnormally high resolutions, the detail view is excessively tiny, so the vast majority of users (especially older ones) require enlarging it. Moreover, there are very popular topics where our members posted skin mods with large fonts and other elements.
Hi Boki,
Colleague, let's look at the raw facts instead of old habits. When a user completely deletes the [rawdisplay] section from the sys.txt, the engine doesn't go blind. It instantly falls back to the default rules inside the data.zip (project_config/igo_nextgen.ini).
Since AnthonyGreek mods the Pongo skin, he uses the data.zip from the Pongo package. If we open that file, we can see exactly what is coded in the native [rawdisplay] section:
[rawdisplay]
;force_renderer="RENDER_MOYA"
always_use_high_precison_in_vs=1
always_use_high_precison_in_fs=1
early_high_dpiclass_round=1
As you can see, the rendering is completely left to iGO and Android to handle automatically. There are no rigid screen restrictions forced here.
This is exactly why Anthony's test in post #84 ended up the way it did. When he left sys.txt blank, the native auto-scaling took over. The 9.35 engine and Android communicated perfectly, and the interface scaled beautifully on its own, providing larger icons and text. It worked so well that his custom, manually enlarged fonts became unrealistically huge on the screen, forcing him to go into his AvSpeed UX and actually decrease the sizes!
I am no programmer, just a truck driver, and I am at the age where I also need +1.5 reading glasses, so I completely understand the need for large, readable layouts while driving. But the reality is: any testing here will only yield as many different results as there are different, customized data.zip files being used by our members. Forcing rigid values in sys.txt usually just chokes the native engine's ability to scale properly.
On any device that is 10 inches or smaller, iGO's native auto-scaling handles the proportions perfectly out of the box. Trying to use monster tablets over 10 inches for navigation is not recommended anyway—mounting them on the windshield is legally forbidden in most countries due to blocking the driver's view, and the software was never tailored for that size. Now, if someone runs it on a regular device and still finds the icons or fonts too small after clearing sys.txt, the correct way is this:
[rawdisplay]
base_dpi=
dpi=
Look, I don't own every single navigation-ready device on the global market. But the 4 different devices I currently run and test all display perfectly sharp and big using this exact method. This forum is weaponized with hundreds of members running all kinds of different hardware. If the community starts testing builds with a blank sys.txt [rawdisplay], we can verify this across dozens of hardwares. Maybe a new direction for the forum?
Last edited by Pasi Sarmos; 26th September 2026 at 08:31 AM.
Bookmarks