How to best handle different sized screens

[Ralim]

With the new S60 and TS101 its has become apparent that the industry is moving to higher resolution displays.
At the moment these are physically similar sized displays,so its really just a DPI increase to allow better quality graphics.

96x16 -> 128x32 is a 1.3x/2x increase so cant trivially scale in firmware nicely. (I tried, its ugly).

How is best to handle this?

The quick and hacky way is just #ifdef everywhere we draw to the screen and swap in logic for the different screen sizes.

However what I'm thinking (and where I would love feedback) is to move this to a pre-compile task like what was done with Translations, where we build the appropriate data only. This means we could have some definition file that defines what is drawn and were on the screen as a big definition of "screens". Then this pre-compile logic can handle different screen layouts and DPI etc.

I've come to this sort of vibe after thinking about the fact we dont have that many different screen layouts:

1. Home screen (basically draws one of two static images)
2. Detailed Home screen
3. Settings Menu, Category
4. Settings Menu, Setting
5. Debug menu (two lines of text)
6. Soldering screen
7. Soldering screen (detailed)
8. Sleep screen
9. Sleep screen (detailed)
10. Warning text screen

On top of this, we can use the script to pre-render fonts at the right dpi for each screen.

So I'm sort of loosely thinking about some form of API on the firmware side that is basically:
OLED::DrawLayout(LayoutEnum layout, param1,param2...);

And we generate layout drawing cpp from the definitions files.

The definition files will need a bit of thought, but roughly thinking they define things being drawn, with entries for both resolutions.

For Fonts, I'm currently tempted to just render all 3 at "current" and scaled size for now. But super open to ideas on how to best handle this. I dont think we should rush to double the information density just as we have higher vertical resolution, as its just getting too damn small 🤣

@discip I would love your thoughts on this especially.
Also, would you be open to making an updated home screen picture at the higher resolution potentially?

[discip]

@Ralim
I'm sorry for replying so late.

As you already know: Programming-wise I accept everything gratefully, no matter which solution you prefer. 😀

For the graphics:
I'm on it, but please give me some time. 😓

[Ralim]

Heya,
Excellent question indeed. My plan if things goes to plan is to see what size works best for the font later on when we are looking at all the pages.

For now I think its best we aim for it to be similar ratio so the buttons look nice / consistent; so leave a 16px gap and we can intially draw in the text with some padding. Then later on when we have higher resolution fonts we can fill in the gap?

I dont have anything to work with at the moment, havent had time to push further forward for a bit sadly.

[discip]

@Ralim
OK, will proceed as you suggest.

I don't know if you've noticed that I've acquired a S60P in the meantime. (#1806)
And I have to say it's pretty decent.

I would love to have IronOS on it to check how the graphics look in person, but unfortunately there is no firmware from SEQURE so I could flash it back to use the iron until IronOS is up and running!

[ia]

I've acquired a S60P
unfortunately there is no firmware from SEQURE so I could flash it back to use the iron

Just my two cents on that if I may. TL;DR: you can try to use dfu-util for dumping original firmware.

So, DISCLAIMER first: I'm not familiar with Sequre products myself so my advice could be completely incompetent & worthless. However, if S60P uses more or less reliable dfu-util "compatible" loader then you can try to dump the firmware since dfu-util is not only for flashing a device but "sometimes" for retrieving original firmware from a device.

Basically, you can try to:

• put the device into DFU mode while connecting to PC with reliable dfu-util implementation;
• run something like dfu-util --upload S60P.HEX (I use gnulinux syntax here just for example).

In fact, now I'm really curious myself will it work or no. I don't remember what the device was exactly but I remember clearly how in the past this exact trick helped me extract firmware from a device once or twice successfully. However, please, keep in mind, that even if dfu-util shows no error/no warning on dumping, but a single bit will be corrupted on transferring/saving, then magic smoke probably will be gone once you flash such firmware back onto iron :(

[discip]

@ia
First of all:
I'm sorry for the late answer.
Unfortunately this device is not recognized by dfu-util.

Thanks for trying to help anyway 😊!

[Ralim]

I dont have a good answer for dumping the existing firmware, I've asked them though :)

[discip]

@Ralim

After having read through this one more time, I totally agree, with what you are heading for here:

However what I'm thinking (and where I would love feedback) is to move this to a pre-compile task like what was done with Translations, where we build the appropriate data only. This means we could have some definition file that defines what is drawn and were on the screen as a big definition of "screens". Then this pre-compile logic can handle different screen layouts and DPI etc.

I've come to this sort of vibe after thinking about the fact we dont have that many different screen layouts:

1. Home screen (basically draws one of two static images)
2. Detailed Home screen
3. Settings Menu, Category
4. Settings Menu, Setting
5. Debug menu (two lines of text)
6. Soldering screen
7. Soldering screen (detailed)
8. Sleep screen
9. Sleep screen (detailed)
10. Warning text screen

I don't know if that makes more sense (or that even matters here), but I think 'debug menu' was somewhat out of place. 😊

1. Home screen (basically draws one of two static images)
2. Home screen (detailed)
3. Settings Menu, Category
4. Settings Menu, Setting
5. Soldering screen
6. Soldering screen (detailed)
7. Sleep screen
8. Sleep screen (detailed)
9. Debug menu (two lines of text)
10. Warning text screen