Inverted display causes offset in image

[xgroleau]

It seems part of the screen is not drawn on when using PortraitInverted or LandscapeInverted, as if the image is outside the screen. Though it's fine using Portrait or Landscape.

I am using st7789_240x240 method since that is the resolution of the display.

I will contact our provider and try to get the exact part number and datasheet.
It's supposed to be a st789v2 with 240x240 pixels.

Here are images of the behavior

[almindor]

This seems like an offset from 320 vs 240. Can you try using the vanilla st7789 constructor and see if that works? I suspect your display has the full 320x240 framebuffer and inverting makes it "scrolled" into the off area.

[xgroleau]

That is what I also suspect, though the "visible" display is actually 240x240. Using the 320x240 results in the same behavior. Maybe my device has a 320x240 frame buffer but a 240x240 display? Could that even be possible?

[almindor]

That is what I also suspect, though the "visible" display is actually 240x240. Using the 320x240 results in the same behavior. Maybe my device has a 320x240 frame buffer but a 240x240 display? Could that even be possible?

Oh yes, that's what most ST7789s are. I'm just wondering where the logical error with the offset is. I'm guessing setting the MADCTL to inverted will simply render "from the other side" so it's all shifted by the hw scroll buffer area (the 80 pixels off screen) so when using Portrait or Lanscape we go from "top to bottom" rendering. But when using inverted we go "bottom to top" where bottom is 320, but the display shows 0, 0 to 240, 240 so we render 80 x 240 pixels "out of view".

[xgroleau]

After testing out a bit, I can confirm that it's rendering out of view by 80 pixels. Maybe this could be fixed with the partial mode display area (PTLAR, 0x30)? I'm not sure though since I just started to work with the device.

[almindor]

After testing out a bit, I can confirm that it's rendering out of view by 80 pixels. Maybe this could be fixed with the partial mode display area (PTLAR, 0x30)? I'm not sure though since I just started to work with the device.

I think the confusion here is in the interplay of inverting and "visible area". Inverting using the MADCTL bit will simply make it consider "0, 0" to be on the other side of the framebuffer, but the visible area is still on the same physical pixels.

I'll think about how to best support those orientations and keep things simple. One workaround for now you can do is to create your own ModelOptions where you provide a custom window offset handler function that gives 80 for the right axis.

This is not correct of course, the driver should handle this internally but until I fix this, you can get things done that way.