Maybe additional IOCTL in touch display drivers, for example here https://github.com/apache/nuttx/blob/master/drivers/input/ads7843e.c#L943
Two calls, one accepting calibration matrix, and another to remove it and come back to raw readings. In typical Linux there is an `xinput` command to do it https://wiki.archlinux.org/title/Calibrating_Touchscreen#Apply_the_Matrix. Am Di., 23. Mai 2023 um 20:37 Uhr schrieb Alan C. Assis <acas...@gmail.com>: > The LVGL 7.x that was integrated on NuttX had a calibration before > initialize the demo, I think it was from LVGL itself. > > There is also TS calibration that Greg created for TWM4NX: > apps/graphics/twm4nx/apps/ccalibration.cxx > > BR, > > Alan > > On 5/23/23, Maciej Wójcik <w8j...@gmail.com> wrote: > > It would be great if NuttX would offer calibration of touch screens out > of > > the box. > > > > I am not sure where it should go, but I think it could be a wrapper that > is > > used by many drivers. > > > > I think we have a similar situation with flash filesystems. There are > > multiple layers that stack on each other. > > > > For example here there is `ftl_initialize` (flash translation layer) and > > then `smart_initialize` (filesystem) > > > https://github.com/apache/nuttx/blob/master/boards/arm/stm32/stm32f103-minimum/src/stm32_w25.c#L266 > > > > Regarding the calibration itself, you probably know how to implement it, > > but otherwise you might find this useful > > https://gitlab.com/nxtlabs/shared-libs/touch-calib-lib/-/wikis/home > > (explanation and implementation) > > > > Coming back to your question, how do other people do it? For me it was > just > > user-space code, part of the application. > > > > Am Di., 23. Mai 2023 um 20:12 Uhr schrieb Tim Hardisty > > <t...@hardisty.co.uk>: > > > >> Hi, > >> > >> This is perhaps more a POSIX/general programming question than NuttX but > >> you are all, so often, so very helpful :) > >> > >> 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). > >> > >> I'm not 100% sure that the chip’s TSD driver is the place to scale it? > >> > >> The TSD driver creates a generic /dev/input0 character driver, which is > >> what LVGL (set via Kconfig) opens. Scaling within the LVGL code isn’t > >> right > >> either, I don’t think? > >> > >> I can only think of either: > >> > >> 1) creating a new character driver that does a translation – registered > >> as > >> /dev/input1 (or whatever) that LVGL uses, and this driver reads input0 > >> when > >> required and returns translated values. > >> > >> 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). > >> > >> Both seem a little messy though so perhaps I’m missing something > obvious? > >> Can't be the first to need to do this? > >> > >> Thanks, > >> > >> TimH > >> > >> > > >
