[Discussion] Add touchscreen calibration for input driver

[TimJTi]

Real world devices often need touchscreen calibration to ensure that touchpoints are correctly reported, and scaled to suit the pixel height and width of the display in use. Algorithms for this are well documented and can handle not just scale and offset but rotation errors too. Floating point maths is needed so it might not be appropriate for all processors of course.

NXWM has a rudimentary scale/offset calibration for touchscreens, and I added an IOCTL to allow the SAMA5D2 TSD device driver to perform a similar function, but I now find I need a better solution with rotational correction too.

It seems to me this could advantageously be an inherent part of the NuttX /dev/input touchscreen drivers, but it would necessitate some non-breaking changes, such as:

1. chip-specific touchscreen drivers would need to move to use the existing drivers/input/touchscreen_upper driver and implement the touchscreen_lower driver instead of the current arch-specific low level drivers.

   • To retain backwards compatibility, each "System Type" Kconfig could have a setting to select between the new and old driver registration methods.

2. For the upper level driver code to be included for the build, the CONFIG_INPUT_TOUCHSCREEN Kconfig setting will need to be selected. This could be done:

   1. Implicitly, via the System Type Kconfig new/old device registration type, if done that way
   2. The "User" board-specfic Kconfig file, or
   3. arch-specific selection, or
   4. Add a generic "arch touchscreen driver" Kconfig option to the main Kconfig section: Device Drivers -> Input Device Support -> arch-specific driver. Something like that.

   I would probably go for i) above

3. Add an IOCTL to touchscreen_upper to set calibration data, and perhaps one to enable/disable its use

4. Add the maths needed to touch_poll to scale the values.

The actual graphical UI needed to capture the points needed for the calibration would not be part of the NuttX OS. I will be implementing an LVGL-based interface for this and others will no doubt want their own flavour anyway.

Storing/recalling/managing the calibration data would be a function of the user app too.

Initially, I would do this for the SAMA5D2, which could act as a template/reference for others should they wish to follow this methodology for other devices.

What do people think?