Dynamic Display Orientation vs Touch

[ImpulseAdventure]

GUIslice provides dynamic screen rotation via GuiRotate() from #72 . As many display devices incorporate a separate touch overlay connectivity and orientation than the screen (GSLC_ROTATE), a touch offset configuration parameter (GSLC_TOUCH_ROTATE) has been provided to enable the display and touch handling to be kept in sync. In most cases, users just need to experiment with the 4 possible GSLC_TOUCH_ROTATE values (0..3) to see which one matches their device.

If dynamic rotation via GuiRotate is not used (meaning that the display always maintains the same orientation as set by GSLC_ROTATE), the current code should support touch handling correctly, provided the correct GSLC_TOUCH_ROTATE value has been set.

However, if dynamic rotation is being used, it appears that the current implementation does not provide automatically correct touch behavior for all screen rotation settings on certain displays (eg. mcufriend).

Next steps:

• Create a sketch that provides screen & touch calibration to determine correct configuration
  • The goal would be to help the user determine the touch pin settings, resistive touch calibration settings and also screen orientation settings
• Revise touch orientation implementation

[ImpulseAdventure]

Some good news on the touch handling front. I have rewritten the orientation & touch handling code and managed to simplify it significantly.

My intention is for the following:

• Base user config only contains GSLC_ROTATE (0..3)
• For resistive displays: config adds the calibration settings ADATOUCH_X/Y_MIN/MAX
• For resistive 4wire displays: config adds wiring settings ADATOUCH_PIN_XP/XM/YP/YM

The plan is to remove all other configuration. This means the elimination of the following from the config:

• GSLC_TOUCH_ROTATE
• ADATOUCH_SWAP_XY, ADATOUCH_FLIP_X/Y
• TOUCH_ROTATION_*

The key change here is that resistive touchscreens will be calibrated in the display’s natural orientation (ie. Rotate=0) using a new diagnostic/calibration sketch. Thus users will need to modify the ADATOUCH_X/Y_MIN/MAX one time to match the output of the calibration sketch.

Dynamic rotation (and the associated synchronization between display and touch) should work automatically.

In total, 3 diagnostic sketches are provided:

• diag_ard_touch_detect: detects pin settings for 4wire resistive displays
• diag_ard_touch_calib: detects touch calibration settings for resistive displays
• diag_ard_touch_test: tests current settings across all rotation modes

Overall, I believe this change will greatly simplify the configuration of the library and also align it with the natural calibration methodology used by other libraries.

The above changes have been implemented in a local development branch and will be posted soon.
If you have any comments or suggestions regarding this approach, please feel free to share your thoughts.

[ImpulseAdventure]

The WIP98_Orientation branch in #105 is now available to test out the rewritten touch handling & orientation code.

Extensive fixes and improvements added, including:

• Rewrite of touch handling & orientation, simplified associated configuration
• Calibration sketches
• Reporting of display & touch driver upon init
• Support for XPT2046_Touchscreen
• Support for HX8347D (including Waveshare 2.8" TFT)
• Support for TFT_eSPI with numerous external touch drivers

Once I have received feedback from others who have had a chance to test out this revised code, I will proceed to merge. Testing with my displays looks good so far, but I would be interested in hearing feedback from others who may be able to try the diag_ard_touch_calib sketch on their resistive displays. In particular, I am looking to see if there might be certain displays for which calibration fails, meaning that additional enhancements to the config may be necessary.

thx

[ImpulseAdventure]

Documentation for the revised touch configuration and calibration steps is now available:

• Configuring Touch Support

[ImpulseAdventure]

The orientation & touch handling update has now been integrated into the master branch from #105. Please see #105 (comment) for specifics.