RE: Touchscreen scaling/LVGL
There is nuttx/drivers/input of course - only just remembered; I'll see if anything "generic" fits there for this. >-Original Message- >From: TimH >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 >>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) >
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 >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)
Re: Touchscreen scaling/LVGL
Thanks Greg – I’ll take a look at those links, and take on board what you’re saying. From: Gregory Nutt Reply to: "dev@nuttx.apache.org" Date: Tuesday, 23 May 2023 at 19:52 To: "dev@nuttx.apache.org" Subject: Re: Touchscreen scaling/LVGL On 5/23/2023 12:11 PM, Tim Hardisty wrote: 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 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)
Re: Touchscreen scaling/LVGL
On 5/23/2023 12:11 PM, Tim Hardisty wrote: 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 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)
RE: Touchscreen scaling/LVGL
Yes, I like the idea of an IOCTL to do this. >-Original Message- >From: Maciej Wójcik >Sent: Tuesday, May 23, 2023 7:39 PM >To: dev@nuttx.apache.org >Subject: Re: Touchscreen scaling/LVGL > >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 >: > >> 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 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 >> > : >> > >> >> 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 >> >> >> >> >> > >>
Re: Touchscreen scaling/LVGL
Yes, using some IOCTL similar to Linux is a good idea. BR, Alan On 5/23/23, Maciej Wójcik wrote: > 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 > : > >> 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 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 >> > : >> > >> >> 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 >> >> >> >> >> > >> >
Re: Touchscreen scaling/LVGL
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 : > 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 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 > > : > > > >> 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 > >> > >> > > >
Re: Touchscreen scaling/LVGL
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 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 > : > >> 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 >> >> >
Re: Touchscreen scaling/LVGL
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 : > 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 > >
Touchscreen scaling/LVGL
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
