Interesting... I appear to have made some progress with this:

I changed two lines of code in https://github.com/rm-hull/luma.lcd/blob/master/luma/lcd/device.py#L301-L303

    def __init__(self, serial_interface=None, rotate=0, **kwargs):
        super(st7789, self).__init__(luma.lcd.const.st7789, serial_interface, **kwargs)
        self.capabilities(240, 240, rotate, mode="RGB")

to become:

    def __init__(self, serial_interface=None, width=240, height=240, rotate=0, **kwargs):
        super(st7789, self).__init__(luma.lcd.const.st7789, serial_interface, **kwargs)
        self.capabilities(width, height, rotate, mode="RGB")

And it allows my 240x320 ST7789 display to show full screen. It doesn't appear, from looking at various demos in luma.examples, to be stretching the pixels across the screen, as circles appear as far as I can tell, to still be circles.

The examples also output the correct dimensions as specified by the .conf file with those above changes:

python3 colors.py --conf ../conf/st7789_240x320.conf
Version: luma.lcd 2.9.0 (luma.core 2.3.1)
Display: st7789
Interface: spi
Dimensions: 240 x 320

However further down at https://github.com/rm-hull/luma.lcd/blob/master/luma/lcd/device.py#L336-L341 there are some hardcoded references to 240 for height and width.

    def display(self, image):
        w, h = 240, 240
        self.set_window(0, 0, w, h)

        image = self.preprocess(image)
        self.data(list(image.convert("RGB").tobytes()))

If I change those, such as making the second value (h) to be 320, I simply get a black display. Leaving them as 240 each allows my 240x320 ST7789 display to work. I don't understand what that is doing.

I've not yet tried the modified code with a 240x240 ST7789 display, but shall give that a try later. I also note that in the class st7789(backlit_device): code there doesn't appear to be any control of the h-offset or v-offset unlike the class st7735(backlit_device, __framebuffer_mixin):, but maybe the ST7789 doesn't have the same issue of where the display is homed to...?

Checked with an Open-Smart 240x240 ST7789 and that is still working correctly with the above code changes.

I've seen there are also 240x135 sized ST7789 displays available, such as:

• https://www.adafruit.com/product/4383
• https://www.aliexpress.com/item/4000533324854.html

I don't currently have any 240x135 resolution displays to test with though.

@matemaciek are you able to help here .. could we change the implementation to not have hard coded width and height please?

I'm definitely for this change, I was polishing already existing pull request and those hard coded dimensions were itching me, but I didn't have different displays to test other sizes. The more generic code is, the better (-:

@SimUKdev your changes make total sense. As for changes in display(), can you try setting w to 320? Maybe the dimensions are swapped there. I also like the version from st7735 and I wouldn't be surprised if it would work on st7789.

I've ordered 135x240 st7789 display, so I will be able to check on it sooner or later also.

@matemaciek

As for changes in display(), can you try setting w to 320? Maybe the dimensions are swapped there.

Just tried both 320, 240 and 240, 320 on w, h = 240, 240 line, and only get a blank black screen when using 320 for either w or h.

Interestingly, if I put 120 for both values, the screen still outputs at what appears to be the same 240x320 (or 320x240) resolution. And just out of curiosity I tried 0, 0 as the numbers being defined there, and that still outputs full screen.

rm-hull reopened this on May 3

so, is this a bug?

I had the same issue with my display (from waveshare). After looking through the code and ST7789 datasheet, it turns out that the arguments to commands should be sent as data bytes, but the library sends it as command bytes. This causes the display to receive a SWRESET command (software reset), because a resolution of 320px is encoded as 0x01 0x3F.

I solved this in pull request #155 by splitting the command and arguments, and forwarding the argument bytes to self.data()

I am also having issues with a device that seems to follow the setup of this product from adafruit https://www.adafruit.com/product/5206
I've also tried modifying the device.py driver file to change the display capabilities to match it being 280x240
But it seems that it will shift my image down and display garbage at the top
putting the number higher only results in this area being filled with whatever was in the top part of the image. (In this case red)