P8: Mirror display for P8b variant

[StarGate01]

This PR has been broken out of #1050, and depends on / includes #1128 .

A new P8b hardware variant requires the display to be mirrored, and the colors to be inverted. Patch provided by @izzeho .

Related: StarGate01/p8b-infinitime#3

[JF002]

This change looks good but... can we try to avoid #ifdefs? I always try to use them as a last resort as I think they make the code more difficult to read and to maintain. Also, as the number of setting increases, the number of add_definitions in CMake will also increase, making it difficult to ensure we'll set consistent values.

Another way to achieve this could be to extend the driver so that it support both modes (mirror and not mirror). The mode would be passed as a parameter of the constructor, and read from a constant (constexpr) when calling the ctor(). constexpr will allow the compiler to optimize (remove) the code that is not used.

Those constants could be listed in header files (1 for each supported variant) and included in main.cpp (the correct.h file will be included using CMake magic or #ifdef).

I think this method will allow to more easily support and maintain multiple variants of the PineTime and the P8. What do you think about this?

[StarGate01]

@JF002 I like the idea of reducing #ifdefs. I used them because they require minimal changes to the code and classes, but I agree that they kind of break the OOP model.

How would you go about writing these variant-specific header files? A file (e.g. src/variants.h), which essentially does a similar selection as the CMake config (https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/src/CMakeLists.txt#L789), i.e. check TARGET_DEVICE, and then define the needed constexpressions, similar to the Pins in drivers/PinMap.h?

I dont think we can get rid of the CMake config completely, because it sets definitions for e.g. the NRF SDK as well.

This could also be used for control of the touch driver behaviour (#1130 (comment)), where @Riksu9000 was rightfully hesitant on littering the code with #ifdefs as well.

The acceleration driver (#1132) is already abstracted and split into multiple classes, so a simple flag can be used to select which implementation to use. I believe link-time-optimization will then remove the unneded code.

[JF002]

@StarGate01 Sorry for the late answer!
I have already investigated some ways to support multiple hardware using a more OOP approach, but I haven't finished those researches yet. The idea was to find a way to correctly encapsulate device drivers so that it's easy to add alternative implementations and support multiple hardware (simulator, other smartwatches like the P8, experiments with the PineDio STACK,...).

I'll try to remember what I've already done (I mean... find the git stash with the code :D) and so we can move forward on that topic!

[StarGate01]

@JF002 regarding encapsulation, what do you think of the approach of #1132 ? There I split the implementations of the device-specific drivers into two specifications of an abstract class. That would be quite a bit of overkill for this PR imho.

I will prepare a variants.h approach as mentioned above, then we can discuss that ?

[Riksu9000]

I think altering a single line with #ifdefs is simple and acceptable. In the case of functions, two or more functions can be defined and #ifdefs only choose which one gets called, which is what I would do in #1130 for example.

[JF002]

Yes, you are absolutely right @Riksu9000, those changes are pretty limited and harmless for the global architecture, and I think we can merge them.

I'm pretty sure we can find a better design than this to support multiple hardware variants, but I unfortunately don't have the time to work on that right now.

So, yeah, let's not block time any further. We'll still be able to improve the design in the future :)