[bug] Reversed behavior of color inversion on ST7789 displays

[alvroble]

While testing the latest commits on the dev branch, I discovered that the color inversion functionality for ST7789 displays is working in reverse.

• When OPTION__DISABLED is set, colors are inverted.
• When OPTION__ENABLED is set, colors are not inverted.

This has no impact during first run since the inversion setting is not applied until its value is explicitly changed.

I verified that @kdmukai used the correct values according to the ST7789 datasheet

The settings flow for

seedsigner/src/seedsigner/hardware/displays/ST7789.py

Line 173 in c735887

self.command(0x21 if enabled else 0x20)

is also correct:

• OPTION__ENABLED → invert(True)

• OPTION__DISABLED → iinvert(False)

Surprisingly, if we swap the values for the inversion commands (0x20 and 0x21), the behavior aligns with what we expect, although that contradicts the datasheet.

This issue is to discuss whether this is a mistake on our side or a discrepancy/error (?) in the datasheet or specific ST7789 variants. I tested this on both a regular 240x240 and a 320x240 ST7789 displays.

[kdmukai]

I verified that @kdmukai used the correct values according to the ST7789 datasheet

A few details:

I can't recall if I did any light tweaks in the older ST7789.py driver, but the basic logic is unchanged since its original inclusion in the project from the beginning. The newer st7789_mpy.py is mostly / entirely(?) a copy-paste from the author noted in its opening comment.

ili9341 dev boards seem to have random differences when it comes to their invert defaults; unit A will render exactly as expected but unit B will be inverted until the invert command is toggled. Because of this, the invert option isn't meant to be a "I want weird colors" option, but rather "uh, my display happens to have the wrong color output so I'll have to guess-and-check that toggle to get it to look right."

I've never seen an st7789 board need the invert toggle.

The invert option for both st7789 drivers was only exposed to match the ili9341 driver so they'd all have a common interface in the new DisplayDriver manager class. If a user will never need to toggle invert on an st7789, perhaps the invert command should just be a no-op for those drivers.

And I'm indifferent if the st7789 toggle is inverted in real life vs what's in the docs. Whichever value gives us the correct rendering should be the default (it sounds like the current default is the opposite?).

[alvroble]

the invert option isn't meant to be a "I want weird colors" option, but rather "uh, my display happens to have the wrong color output so I'll have to guess-and-check that toggle to get it to look right."

This is key. I somehow believed this was some weird UX feature, not a "fix my display" feature.

Right now, as you say we haven't heard of any known cases of inverted colors for ST7789, but I'd rather not remove this option if it's already there. We don't know if in the future there can be a defective batch with inverted-color. Maybe what we should do is just swap the 0x20 and 0x21 values to make it work as expected, based on the empirical testing. Right now, if you call invert(False) in the display driver, the colors get inverted, so it's just a minor bug with no effect because it has rarely been used.