Make displayio more flexible to support more controllers (like the one in Waveshare 1.54inch e-Paper V2)

[dquadros]

At the moment displayio makes many assumptions on the format of the display controller commands, limiting the controllers it can support.

In my particular case I tried to create a driver for the Waveshare 1.54inch e-Paper V2 display (datasheet). While the display has a 200x200 pixels resolution, the row addressing commands (0x45 and 0x4F) use a two byte, LSB first, parameter for the row. Function displayio_display_core_set_region_to_update() (at displayio_core.c) assumes a one byte parameter for self->ram_height less than 256 and a two byte (MSB first) parameter for self->ram_height greater than 255.

To support this controller there is a need of a more flexible way to specify the format of row addressing commands (or a way to override this in the python code, which would probably have performance issues).

[tannewt]

It looks like this display is using an SSD1681: https://www.good-display.com/product/208.html

We have a CircuitPython driver for it here: https://github.com/adafruit/Adafruit_CircuitPython_SSD1681/blob/main/adafruit_ssd1681.py

The main trick is that you can set ram width >256 but then say this display is only 200 wide. That'll use the two byte form but only compute 200 pixels wide.

[dquadros]

It looks like this display is using an SSD1681: https://www.good-display.com/product/208.html

We have a CircuitPython driver for it here: https://github.com/adafruit/Adafruit_CircuitPython_SSD1681/blob/main/adafruit_ssd1681.py

The main trick is that you can set ram width >256 but then say this display is only 200 wide. That'll use the two byte form but only compute 200 pixels wide.

I actually tried that before opening this issue... It does not work because the byte order for the row is different. In display_core.c we have:

if (self->ram_height < 0x100) { data[data_length++] = y1; data[data_length++] = y2; } else { data[data_length++] = y1 >> 8; data[data_length++] = y1 & 0xff; data[data_length++] = y2 >> 8; data[data_length++] = y2 & 0xff; }

The display datasheet (and the manufacture's example code) shows:

Anyway, thanks for the fast reply!

[tannewt]

Ah ok. @makermelissa wrote that driver and can let us know why it is that way. We could add a flag for byte order if needed.