drivers: display: st7789v: implement display_set_orientation API

[LuskeyNoah]

Add support for 135x240, 240x320, 240x240 displays at 0, 90, 180, and 270 degree orientation.

closes #32286

[Snevzor]

Hello @LuskeyNoah, I'm also working on a similar PR for the ssd16xx driver (but focusing on setting the orientation in the DTS first in combination with correct LVGL init). I'm curious why you chose not to switch x/y_resolution in the get_capabilities function, wich is done here: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/display/display_ili9xxx.c#L246.

I was traveling the ili9xxx road and got into an issue by switching those parameters in the get_capabilities function. LVGL init fails because this bit of glue code here: https://github.com/zephyrproject-rtos/zephyr/blob/main/modules/lvgl/lvgl.c#L107. The allocation function assumes X matches the display width and Y matches the the display height, which is not the case anymore when the display driver already has them switched. As a result, the lvgl_init fails for non-square resolutions.

I decided that the driver does not need to switch the resolutions (like with your implementation), but then LVGL needs to do it, so I think the glue code needs a "disp_drv.rotated = ..." (in lvgl_init()) based on the current orientation from the display capabilities. This is what I'm going for at the moment but I wonder if touching the glue code like that will break other display orientation implementations.

Also, based on my findings I actually think that ili9xxx + lvgl sample does not work currently when the orientation is 90/270 degrees (as initial orientation, using dts), but I cannot verify because I lack the necessary HW to test.

What are your thoughts on this?

[LuskeyNoah]

I'm curious why you chose not to switch x/y_resolution in the get_capabilities function, wich is done here

@Snevzor - good catch. This is an oversight on my part. I'm pushing an update, as it looks like other drivers choose to take the approach of reporting the swapped dimensions.

[Snevzor]

@LuskeyNoah I'm still a bit confused about the correct approach on this. Please refer to my comment here: #73360 (comment).

[LuskeyNoah]

I do not have the proper hardware to confidently/fully test this. Closing. @Snevzor please reopen and/or contribute to it if desired. I will reopen if I can fully test this.

[Snevzor]

@LuskeyNoah I unfortunately also do not have a st7789 based display laying around, I'm sorry.

[DBS06]

Hi, because I opened a PR for porting the Adafruit Feather ESP32-S2 (#85405) and I have a Adafruit Feather ESP32-S2 TFT which has a ST7789v and a "1.14" IPS TFT with 240x135 pixels" (actually the pixels are 135x240).
I tested the code with the samples/subsys/display/lvgl sample, the orientation change works in principal.

My first approach was this:

	int err = display_set_orientation(display_dev, DISPLAY_ORIENTATION_ROTATED_270);
	if (err == 0) {
		LOG_INF("Display orientation set to rotated 270 degrees");
	} else {
		LOG_ERR("Failed to set display orientation");
	}

The rotation works in principal but it gives me this result:

This looks like lvgl does not recognize a change in orientation from the display-driver-module. So I tried the following: set CONFIG_LV_Z_AUTO_INIT=n and called lvgl_init() after changing the orientation, but actually this had no effect at all.

After that I tried to just use lv_display_set_rotation(lv_display_get_default(), LV_DISPLAY_ROTATION_270); and had the following weird result:

By doing both display_set_orientation() and lv_display_set_rotation(), unset CONFIG_LV_Z_AUTO_INIT=n and not calling lvgl_init() manually, see code-snippet here:

	int err = display_set_orientation(display_dev, DISPLAY_ORIENTATION_ROTATED_270);
	if (err == 0) {
		LOG_INF("Display orientation set to rotated 270 degrees");
	} else {
		LOG_ERR("Failed to set display orientation");
	}
	lv_display_set_rotation(lv_display_get_default(), LV_DISPLAY_ROTATION_270);

It works as it should:

My branch can be viewed here:
https://github.com/DBS06/zephyr/tree/st7789v_implement_display_set_orientation_API

If this behavior is acceptable I would reopen this PR.

[Snevzor]

Hi @DBS06,

For this to work well with LVGL this is needed: #73556.
Also, in context to why this PR was abandoned, #82582 needs to be clarified fist. --> for this PR I think your best bet is to make sure the driver doesn't switch x/y resolution and then to test with the changes from #73556.

Maybe check with @danieldegrasse?

Br,
Sven

[DBS06]

@Snevzor Thanks for the fast response and clarification!