There is nuttx/drivers/input of course - only just remembered; I'll see if anything "generic" fits there for this.
>-----Original Message----- >From: TimH <t...@jti.uk.com.INVALID> >Sent: Wednesday, May 24, 2023 12:04 PM >To: dev@nuttx.apache.org >Subject: RE: Touchscreen scaling/LVGL > >I'm thinking: > >1) that the LVGL Gregory linked to is a contender for the graphical >interface, only for LVGL of course, to do the calibration >2) The existing calibration routines in nuttx-apps (e.g. ccalibration for >NXWM as suggested by Alan C. Assis) is a great alternative for non-LVGL >implementations >3) Developers can write their own front end if preferred. > >All produce the necessary offsets and scale factors etc. > >In my case, the screen is only used by pudgy, often gloved, fingers so >absolute accuracy is not required; any variations between displays are >not an issue as there are large touch button areas that are difficult to >miss! > >That just leaves the question of where/how to calculate compensated x/y >co-ordinates that take the offsets into account. > >I see there is CONFIG_TSCALIBRATION used by platform_setconfig, currently >only used by mikroe boards that I can see, along with some structs (i.e. >sCalibrationData) but there is no "generic" TSD driver in nuttx/drivers. > >Perhaps that is something that one day might be a useful enhancement, as >it could then standardise the struct(s) etc. and provide "methods" along >the lines of efuse, power/supply, and so on. > >Ultimately, the offsets/scaling do need to be applied somewhere though, >and to me, IOCTL to the ADC driver feels right. In the case of the SAMA5 >a read via the character driver is what actually initiates a TSD sample, >so the overhead of calculating offsets seems acceptable, but other >processors/implementations could do this on a timer etc so it's not a >definitive approach. > >I will implement IOCTLs, using the sCalibrationData struct as the >argument and see how I get on. > >>From: Gregory Nutt <spudan...@gmail.com> >>Sent: Tuesday, May 23, 2023 7:51 PM >> >> >>On 5/23/2023 12:11 PM, Tim Hardisty wrote: >>> Hi, >>> >>> >>> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y >>coordinates scaled 0-4095. >>> >>> LVGL wants them scaled to the actual size of the display (800x480 in >>> my >>case). >>> >>> 2) Enhance the chip's TSD driver after all, using a Kconfig setting >>> to >>enable X/Y scaling to the display's size (set in board-specific files >>already). >>> >> >>Many touchscreens require calibration by the application via a >>calibration screen. Hence, only the application knows the scale >>factors to use and so scaling is done by the application. >> >>Scaling could also be done by the driver using calibration information >>provided via an IOCTL. All resistive touchscreens require calibration. >>If your touchscreen does not require calibration, then I suppose it >>could even be provided by a configuration setting. >> >>Raw, unscaled input is also needed by the application, however (in >>order to do calibration, for one). >> >>Scaling in the driver could also be inefficient since the driver does >>not know if the sample will be used or not. It might be better to to >>scale in the application even if calibration is not necessary. >> >>A quick Google provides some references for touchscreen calibration >>with >>LVGL: >> >> * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244 >> * https://github.com/jakpaul/lvgl_touch_calibration >> >>The are other calibration displays under nutts-apps/ (not for LVGL) >
