How to handle new display types

[danielkurek]

I am working on supporting MHP50 (#1872) which has color LCD instead of OLED. I have gone through the codebase and compiled a list of files where is the OLED library hardcoded (excluding port specific files and UI/drawing) and what functions are used there:

• BootLogo - clear, draw area (also swapped), refresh
• lang_multi - print whole screen
• ScrollMessage - clear, cursor, print
• SettingsGUI - print, cursor, refresh, draw unavailable icon, rotation, print symbol deg, draw checkbox, brightness, inversion, clear
• GUIThread - clear, display state (on/off), use secondary framebuf, transition (scroll, secondary framebuf), refresh, initialize, brightness, inversion, rotation
• MOVThread - rotation
• CJC - cursor, print
• HomeScreen - rotation, cursor
• SettingsMenu - print, cursor, scroll indicator
• USBPDDebug_FS2711 - refresh

I have two solutions to this problem but I would like to hear opinion of current maintainers because I am not deeply familiar with IronOS codebase (nor do I have experience with larger embedded projects).

1. The quick and dirty solution - add feature flag for LCD display and basically duplicate all sections that use OLED and replace OLED for LCD.
   • no performance penalty
   • less readable code especially with more screen types
2. Make common interface for all screen types that would handle basic operations with the screens (init, screen width and height, cursor, print, draw, clear, refresh, rotation, brightness, inversion). Each screen driver class would also have methods outside of the common interface in order to support screen specific features.
   • can lead to some performance penalty depending on the implementation
   • full color support of LCD will be hard to achieve in the common interface without performance impact
     • also color displays may have performance penalty when working with monochrome common interface (I am not sure about this one, there might be some trick or hardware feature that I do not know about for converting bitmap to RGB)
   • better code readabilty
   • better extendibility for new screens
   • possible implementations:
     a) Each class would implement required common functions. Than we could create a type alias in the configuration files of each port for the required screen class.
     b) Or better solution is template class that would be just a wrapper for the screen specific functions. This approach would allow more freedom in the screen driver class but than some screen specific conversion would be needed in the wrapper.

I am not fan of first solution because if there would be another display that would be supported, it would lead to quite messy code IMHO. However, second solution comes with some drawbacks, mainly that the common interface would need to be monochrome in order to not introduce any performance penalty or break compatibility (due to increased RAM usage) for devices with monochrome displays (don't know if this is a real concern).

@Ralim @discip (or someone else) let me know what do you think of suggested solutions or how would you add support to different screen types.

[Ralim]

Hello,

This is a topic I've known is coming for a loooong time.
The work to split the screen drawing implementations into folders here was started with support for LCD displays as the end goal.

I've had many issues in the past with C++ interfacing/classes not being a 0 cost abstraction at the end, and we are fairly tight on code size overhead [1]. So I instead leaned towards not adding any more and instead we would make an implementation for each basic screen type (Currently large/small monochrome OLED's).

I expect to move the remaining OLED calls that exist outside that folder to instead being functions at are implemented in the UI folder set and so their actual implementation is swapped out at build time. I just haven't yet gotten to moving those calls out.

This is effectively option (1) in a slightly more organised manner (I think). It does result in duplicated code per screen, but to be honest so far, its significantly more readable and easier to maintain than when we had #ifdef's or extra abstraction. So I'm leaning towards the duplication as it makes the reading of the code simpler.

---

I actually have a long term goal, (for when I have more than like an hour a week to work on this) to actually machine generate a lot of these implementations at compile time from a yaml/json markup for the screen layout. Since a lot of these is basically the same thing with just different fonts/colours/positioning. Which can be compile-time determined.

Flash and RAM usage is absolutely a concern, and honestly is generally more limiting than processing speed. For certain devices (TS80P) we have bounced off being out of flash size more than once and had to get crafty flagging features. In general Miniware devices are often the worst for available flash size as they tend to like to claim large chunks for their bootloader and then not use that space.

---

[1] I do long term intend to remove a lot of the current C++ classes for plain C to re-gain some code size, but haven't had time.

[danielkurek]

Ok, thanks for the info. So should I write the new LCD driver in plain C?

---

How should I handle icons? The display is the same size (0.96") as others but with higher pixel density (80x160) so the icons will probably need to be larger. Should I scale them manually or is there some process for it? Also do we want to support multi-color icons?

I do not need the icons anytime soon, it will probably take a couple of months until I get the MHP50 to usable state. I will start with the icons that are already in IronOS and draw them in single color.

[Ralim]

Ok, thanks for the info. So should I write the new LCD driver in plain C?
C or C++; whichever is easier or more comfortable. I dont mind either way.

---

How should I handle icons?

There isn't yet any real tooling around this. I'm open to any real ideas here as its something I haven't yet decided upon. I prefer solutions that are compile time, but it may make more sense for this to have code that just draws icons at 2x scale perhaps (for now?).

I think for a lot of things being able to draw a b&w icon with a colour applied (i.e specify a base icon + colour) would work, rather than encoding icon versions in colour. But I'm super flexible here in terms of what is easier, is easier. And we can always optimise once its working.

[Ralim]

Just as an update to this; I might try and take a stab at a driver for one of this series of display for some testing in the coming weeks. So if you leave the graphics to last; I might get it done by the time you get there

[danielkurek]

I have already started working on it in my fork. The initialization should be complete (some values in init_cmd_list might have to be changed for the specific displays) but I haven't had the time to test it. You can pick up where I left off or you can just copy some parts of my code. I will probably not have the time to work on in the coming weeks. If anything changes I will let you know.

[Ralim]

Ah in that case keep going :)
The dev board I have here has a different lcd module but still its a colour lcd. So if I get there (and dont get busy as well) we can swap implementations 🙇🏼