Touch rotations don't match screen rotations.

[rosenhauer]

When using the TF6202/XPT2046 touch screen plugin and AdafruitGFX quick start for 5110, ST77xx and ILI9341 the Rotation settings of the Touch and display don't match up.

With XPT2046 and ILI9341

Touch\Display          | 0 (Portrait 0) | 1 (Landscape 90) | 2 (Portrait 180)| 3 (Landscape 270)| 
Portrait (0)           | Touch + 90     |  Correct         | xxxxxxxxxxxxxx  |  xxxxxxxxxxxxxx  | 
Portrait Inverted (1)  | Touch + 90     |  Correct         | xxxxxxxxxxxxxx  |  xxxxxxxxxxxxxx  | 
Landscape (2)          | V=OK H=Inverted|  xxxxxxxxxxxxxx  | xxxxxxxxxxxxxx  |  xxxxxxxxxxxxxx  | 
Landscape Inverted (3) | V=OK H=Inverted|  xxxxxxxxxxxxxx  | xxxxxxxxxxxxxx  |  xxxxxxxxxxxxxx  | 

Note: I didn't test the xxxxxxxxxxxxxx cases.

It appears that the Touch rotation only changes line 23 in XXX_menu.cpp to the 4 different enums listed in iotouch::TouchInterrogator and this doesn't rotate it the same as the display rotation.

If the Touch Rotation is left at the default (PORTRAIT) and a line is added in tcMenuAdaTouchDriver.h after line 39 with: theTouchDevice.setRotation(x); This is immediately after the theTouchDevice.begin(); statement Where the number (x) is the screen rotation setting (same as in gfx.setRotation(x); line of xxx_menu.cpp). Then they match up correctly.

For example to use Screen rotation = 2 (Portrait 180) you would have the following. ` tcMenuAdaTouchDriver.h void init() { theTouchDevice.begin(); theTouchDevice.setRotation(2); }

XXX_menu.cpp // Code generated by plugins. gfx.begin(); gfx.setRotation(2);

`

[davetcc]

This is intended, not all touch devices line up with their screen counterparts. This allows it to be configured separately.

[davetcc]

In fact out of the 4 touch boards I have one of them has different rotations. The resistive touch screen IIRC. Also you could see a situation where the touch overlay was applied wrongly on a batch and needed inverting.

[rosenhauer]

Yes, mine is a cheap resistive screen.

Could you add a second rotation config to the touch screen. The current one looks like it works by adjusting the MenuTouchScreenManager. Maybe add another optional one that takes the numeric value (like the screen) and sets the .setRotation(x) on the screen itself? That way depending on the screen you have you would have full control to have the editor set the values and not have to edit code every time you make an update.

[davetcc]

I'm not sure I fully understand, there is a rotation on both the adafruit plugin that controls the display's rotation, and another on the touch input plugin that controls the rotation for that.

For the display (see display rotation parameter in image below):

For the touch input plugin (see rotation parameter in image below):

Not sure I've fully understood. Is there something I'm missing here?

[rosenhauer]

The one on the Touch interface doesn't, as far as I can see, set the touch.setRotation(n). It just applies post processing in the calibration functions.

I couldn't with any of the 4 touch settings get the touch orientation to align with the screen in portrait mode.

That's why I suggested a second setting to directly set the driver level setRotation(x) and then the current setting would handle the cases where the y-Axis he's to be inverted in addition to rotation.

[davetcc]

Thanks, I think I understand now, I'm in the middle of tidying up the touch screen support at the moment. One of the issues for me is that I often use the same example to test something. They were often written one or two years ago, meaning that I forget all the steps I did to get something working.

What I'll do is, once I've finished the refactoring of the touch interface, I'll start an example from scratch with the same library to ensure I've got all the edge cases.

[davetcc]

Agreed, this was implemented fundamentally wrong when I thought about it again. It is not a display, it's a sensor effectively glued to the top of the display, it could be out in any number of dimensions.

In 3.1 all the touch plugins will take three parameters that describe the way that the sensor is to be used by IoAbstraction:

• Are the values to be sent in XY or YX format, IE is XY to be swapped.
• Do the X values need to be inverted
• Do the Y values need to be inverted

It's a breaking change, but it is really needed for it to work with the full range of setups.

This should give complete control over the touch sensor, and allow for nearly any scenario.

[davetcc]

Let me know if you can think of anything else that could differ between panels, will be easy to add while I'm doing this.

[davetcc]

With 3.1 of IoAbstraction and tcMenu, the orientation allows for complete control of each axis.