When the colours are wrong

Diagnose it before you change anything

Fill the screen with pure red, then green, then blue, and leave a black bar somewhere you can see. Then read the symptom.

Three symptoms, three causes, and the black bar is what separates them.

Black is the tell

If black is still black, only the channel order is wrong. The panel wants its three colour channels in the opposite order from the one being sent, so red and blue trade places and green — which sits in the middle — is unaffected. That is setColorOrder().

If black has come out white, the panel is inverted. Every value is being displayed as its opposite, which is a single bit in the controller and a single call: setInverted().

If red is arriving as yellow, both are wrong at once. It looks exotic and it is not: invert red and you get cyan, then swap cyan's channels and you get yellow. Two calls, and the arithmetic is worth following once so the symptom is recognisable on sight.

One exception, on two panels

Both fixes are live register writes on the ST7789 and ST7796 panels — the 2.0, 2.4, 2.8 and 3.5 inch — so a test sketch can sweep them without recompiling.

The 0.96 inch and the 1.8 inch are ST7735, where the drawing library underneath takes colour order as a constructor argument rather than a register write. On those two, setColorOrder() has to come before begin(). It returns false if you call it too late rather than quietly doing nothing, so a wrong-looking panel and a false in the log are the same problem.

LB_Display display(LB_TFT_18);

void setup() {
  display.setColorOrder(LB_Display::COLOR_BGR);   // before begin() on ST7735
  display.begin();
  display.setInverted(true);                      // any time, on any panel
}

Why this article exists at all

The panel table that makes every other part of this kit a one-line change is honest about its own limits: the colour order and inversion flags in it have not been measured on a kit panel. The library's own file says so in a warning at the top, and it flags the 1.8 inch outright as unverified — the old Arduino sketches and the old MicroPython scripts disagreed about that panel, and nobody noticed for a long time because the test drew unlabelled colour bars. You cannot tell red from blue in a bar with no caption.

So treat the flags as very likely right and immediately checkable. Run the self-test, look at the labelled bars, and if a panel is wrong you now know which call to reach for.

And if it is a panel we sell, say so rather than working around it in your sketch. The value belongs in panels.yaml, where both languages pick it up and the next person does not have to find it again.