HX8357: Mirroring and Color issues

[Tetrikus]

If I just use the library as it is, my displays (HX8357d) have two issues:

• The displayed image is mirrored X <-> Y
• The colors seems kind of inverted (or maybe better just BGR instead of RGB

I tried the following:

Adafruit_CircuitPython_RGB_Display/adafruit_rgb_display/hx8357.py

Line 96 in 2c4d380

(_MADCTL, b"\xa0"),

I changed (_MADCTL, b"\xa0") to (_MADCTL, b"\x20")

This fixes the mirroring of the image.

But the colors are still behaving odd. Some JPG images are displayed correct (does this make any sense?). But most (PNG and JPG) look inverted (except white and black). Also, if I draw text, the colors are displayed in BGR instead of RGB. Any idea how I could adapt the library to fix this as well?

(_COLMOD, b"\x55"),  # 16 bit
(_MADCTL, b"\xc0"),
(_TEON, b"\x00"),
(_TEARLINE, b"\x00\x02"),  # TW off
(_SLPOUT, None),
(_MADCTL, b"\x20"),
(_DISPON, None),

[FoamyGuy]

One of the bits in the MADCTL register is supposed to control RGB or BGR mode according to the datasheet

I think maybe you could use (_MADCTL, b"\x28") instead of \x20 in order to flip that bit to 1, but leave the change you made to mirroring as well.

[Tetrikus]

That's it! I tried with b"\x21", but never with b"\x28". Now I did and it works as expected! Thank you so much!

I'm still not sure, whether I should close this issue, since this feels a lot like a workaround to change these values. Shouldn't one expect to have the correct values for the according screens?

[FoamyGuy]

@Tetrikus What kind of displays do you have? Are they Adafruit hardware? or if not where did they come from. Can you post a photo?

If they are from another source it may just be that they are configured differently from the Adafruit breakouts that use this display driver.

I tested this library by running a slightly modified version of: https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/blob/main/examples/rgb_display_hx8357test.py on https://www.adafruit.com/product/3651

I changed the location of the single pixel plot to place it along different edges and corners of the display to verify the mirroring behavior. In my case with this setup the display is working correctly, both color and pixel positions with the default values that are currently in the driver code with no modifications.

If different configurations of display are prevalent perhaps we'd be willing to accept a PR that adds an argument to the constructor to allow user code to pass this value in. It'll be slightly tricky in that it needs to iterate _INIT to find the right entry to modify / overwrite, but I think it could work, though only after a quick glance it's possible there is some other issue with this approach.