Inconsistency between display rotation and touchscreen coordinate rotation using Bodmer's TFT_eSPI library for both units

Description

Inconsistency between display rotation and touchscreen coordinate rotation using Bodmer’s TFT_eSPI library for both units.

What MCU/Processor/Board and compiler are you using?

ESP32
TFT-Display with ILI9341 (240x320)
Touchpad XPT2046

What LVGL version are you using?

Ver. 9.2.2

In this case, both the display and the touchpad, are connected on the same SPI bus but obviously with different Chip select signals.

After a long search in various forums and without finding exhaustive answers, I decided to get into the heart of the matter, looking more closely at what the TFT_eSPI code and the LVGL code do in the case of rotation.

I do not hide that it took me several days to understand why the display rotation (in the various angles) did not correspond with the coherent rotation of the touchpad in the LVGL environment.

In the case of rotation both codes (LVGL and TFT_eSPI driver) intervene to adjust their operation also in relation to the touchpad.
This must be avoided, otherwise the results relating to the X,Y coordinates of the touchpad will be wrong.
(See getTouch() function in TFT_eSPI library)
(See indev_pointer_proc() function in lv_indev.c file)

Both modules try to do the same thing twice with obviously wrong results.
I believe many Touchpad drivers do the same thing.

In my case I decided to comment out the part in LVGL scope.
(see photo)

Furthermore, at each rotation it is necessary to adjust at least one touchpad parameter based on the rotation. (see calData[4] ).
(see photo)


At each change of display rotation this parameter must also be updated. (see code below).
By doing this the X,Y coordinates will always be correct, regardless of the display rotation, and it will no longer be necessary to do the swap(X,Y) in any case.

my approach was this… hope this help
(see below)


////////////////////////  CalData declaration for all rotation ////////////////////////
uint16_t calData_0  [5] = { 377, 3375, 237, 3512, 2};   // TouchScreen calibration for rotation 0   (Portrait)
uint16_t calData_90 [5] = { 253, 3507, 363, 3411, 1 };  // TouchScreen calibration for rotation 90  (Landscape)
uint16_t calData_180[5] = { 253, 3507, 363, 3411, 4 };  // TouchScreen calibration for rotation 180 (Portrait  flipped)
uint16_t calData_270[5] = { 253, 3507, 363, 3411, 7 };  // TouchScreen calibration for rotation 180 (Landscape flipped)
///////////////////////////////////////////////////////////////////////////////////////

/*Set to your screen resolution and rotation*/
#define TFT_HOR_RES   240
#define TFT_VER_RES   320
#define TFT_ROTATION  LV_DISPLAY_ROTATION_90




/////////////////// Display initialization   ///////////////////////////////
/*TFT_eSPI can be enabled lv_conf.h to initialize the display in a simple way*/
disp = lv_tft_espi_create(TFT_HOR_RES, TFT_VER_RES, draw_buf, sizeof(draw_buf));

lv_display_set_rotation(disp, TFT_ROTATION);   // Set display rotation 
Touch_SetRotation(disp, TFT_ROTATION);         // Adjust Touch rotation




////////////////////////   SERVICE  ////////////////////////////////////////
void Touch_SetRotation(lv_display_t * disp, lv_display_rotation_t rotation)
{
  lv_tft_espi_t * dsc = (lv_tft_espi_t *)lv_display_get_driver_data(disp);

  switch(rotation) {
    case LV_DISPLAY_ROTATION_0:
         dsc->tft->setTouch(calData_0);      /* Portrait orientation so invert X-Axis */
         break;
    case LV_DISPLAY_ROTATION_90:
         dsc->tft->setTouch(calData_90);     /* Landscape orientation so rotate touch */
         break;
    case LV_DISPLAY_ROTATION_180:
         dsc->tft->setTouch(calData_180);   /* Portrait orientation flipped so invert Y-Axis */
         break;
    case LV_DISPLAY_ROTATION_270:
         dsc->tft->setTouch(calData_270);   /* Landscape orientation flipped so rotate touch, invert X-Axis, invert Y-Axis */
         break;
  }

}


//////////////////////////////////////////////////////////////////////////////////

I imagine there may be more elegant solutions, but I think they may come from others