nanogui: Thread: touchscreen calibration

Hi Alex,

I am modifying mou_ads.c, and I have some questions for you.

In mou_ads.c I am editing PD_SetCalibration() because it seems there is no
SetCalibration() function in this file.

In PD_SetCalibration() I have added the following code:

	if(mousedev.mode == MWMOUSEMODE_RAW) {
                ioctl(pd_fd, SHOULD_KERNEL_SCALE_DATA, NO);
        } else { 
                ioctl(pd_fd, SHOULD_KERNEL_SCALE_DATA, YES);
                ioctl(pd_fd, 10, mousedev.xmin);                //sets min x
                ioctl(pd_fd, 3, mousedev.xmax);                 //sets max x
                ioctl(pd_fd, 11, mousedev.ymin);                //sets min y
                ioctl(pd_fd, 4, mousedev.ymax);                 //sets max y
                ioctl(pd_fd, SET_Z_THRESHOLD, mousedev.zthresh);
        }

As you can see, there are some values I still have to edit.  For reference,
here is what the ioctl arguments look like for the ADS Graphicsmaster
platform (this is taken from linux/drivers/char/ucb1200_ts.c which might be
specific to my platform):

      	case 3: 
           raw_max_x = arg; 
           break; 
        case 4: 
           raw_max_y = arg; 
           break; 
        case 5: 
           res_x = arg; 
           break; 
        case 6: 
           res_y = arg; 
           break; 
        case 10: 
           raw_min_x = arg; 
           break; 
        case 11: 
           raw_min_y = arg; 
           break; 
        case 12: 
  /* New attribute for portrait modes */ 
           xyswap = arg; 
  /* Allen Add */ 
        case 13:         /* 0 = Enable calibration ; 1 = Calibration OK */ 
           cal_ok = arg; 
        case 14:         /* Clear all buffer data */ 
           ts_clear(); 
           break; 
        case 15:         /* X axis reversed setting */ 
           x_rev = arg; 
           break; 
        case 16:         /* Y axis reversed setting */ 
           y_rev = arg; 
           break; 
        case 17:         /* Clear all buffer data */ 
           print_par(); 
           break;


Looking at this, I see no cases for "SHOULD_KERNEL_SCALE_DATA" and
"SET_Z_THRESHOLD".  Should I remove the ioctl lines from my code that deal
with these two?  Also, is "MWMOUSEMODE_RAW" something I have to edit?

Cheers,
//Henry Chea
Semcon Sweden AB

-----Original Message-----
From: Alex Holden
To: Henry Chea
Cc: ####@####.####
Sent: 3/11/2002 8:13 PM
Subject: Re: [nanogui] touchscreen calibration

Henry Chea wrote:
> I have no idea what needs to be done to fix the ADS platform for use
with
> the new calibration functionality.

If you want to have a go at this, apply the attached patch to a recent 
snapshot of my tree, and fill in the contents of the SetCalibration() 
function in src/drivers/mou_ads.c

What it should do is something like (in pseudocode):

if(mousedev.mode == MWMOUSEMODE_RAW) {
	ioctl(pd_fd, SHOULD_KERNEL_SCALE_DATA, NO);
} else {
	ioctl(pd_fd, SHOULD_KERNEL_SCALE_DATA, YES);
	ioctl(pd_fd, SET_MIN_X, mousedev.xmin);
	ioctl(pd_fd, SET_MAX_X, mousedev.xmax);
	ioctl(pd_fd, SET_MIN_Y, mousedev.ymin);
	ioctl(pd_fd, SET_MAX_Y, mousedev.ymax);
	ioctl(pd_fd, SET_Z_THRESHOLD, mousedev.zthresh);
}

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
 <<touchscreen.patch>> 

Henry Chea wrote:
> In mou_ads.c I am editing PD_SetCalibration() because it seems there is no
> SetCalibration() function in this file.

That's right.

>         case 5: 
>            res_x = arg; 
>            break; 

You may possibly have to set these values yourself to the display 
resolution (or it may be done by the kernel framebuffer code when the 
framebuffer size is set).

>         case 13:         /* 0 = Enable calibration ; 1 = Calibration OK */ 
>            cal_ok = arg; 

I'm not sure what that does. Check to see what cal_ok is used for; it 
may possibly put the driver into a raw ("calibration") mode.

> Looking at this, I see no cases for "SHOULD_KERNEL_SCALE_DATA" and
> "SET_Z_THRESHOLD".  Should I remove the ioctl lines from my code that deal
> with these two?  Also, is "MWMOUSEMODE_RAW" something I have to edit?

For SHOULD_KERNEL_SCALE_DATA what you'll need to do is put the device 
into a mode where it doesn't do any scaling on the data when the driver 
asks for MWMOUSEMODE_RAW. If there isn't any specific ioctl that can do 
that, you could set the calibration values (xmin, xmax, ymin, ymax) to 
the limits of the values supplied by the chip (IIRC, I think they are 
0-1024 in both axes).

For SET_Z_THRESHOLD, you need to find out what the third byte of the 
data packet from the kernel is. If it is a raw pressure value, (which is 
what you want really so you can supply it to the client applications), 
remove the SET_Z_THRESHOLD ioctl, and modify the PD_Read() function so 
that instead of:

         if(data[2] > 0) {
                 *pb = MWBUTTON_L;
                 *pz = 100;
         } else {
                 *pb = 0;
                 *pz = 0;
         }

You have something like:

	*pz = data[2];
	if(data[2] > mousedev.zthresh) *pb = MWBUTTON_L;
	else *pb = 0;

If the kernel handles the z threshold itself and just returns a 
true/false "button is pressed"/"button is not pressed", then remove the 
SET_Z_THRESHOLD ioctl() and live with the fact that you have no way to 
calibrate the value and no way for clients to make use of the pressure 
information the device provides (or hack the kernel driver so it returns 
the raw pressure information and do what I said above).

If your driver does return pressure information and you make the 
modification to set *pz properly, have a go with the "pressure" demo 
(you may need to mess with the calibration values in 
demos/nanox/pressure.c). It's a version of the classic "scribble" demo 
but with the width of the line varying depending on how hard you press- 
it's quite fun on the TuxScreen.

BTW, I personally think the scaling and filtering is all best done in 
user space anyway, like the new ucb1x00 driver.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

Alex & others,

Sorry I didn't get a chance to edit the ADS touchscreen driver earlier.  But
the hardware I was working on has just gotten shipped away, so I am no
longer able to work on adding the new calibration scheme to the driver.
Does anybody else have an ADS Graphicsmaster platform they're willing to
continue the development with?  If so, perhaps I can help point you in the
right direction.

Cheers,
//Henry Chea
Semcon Sweden AB

-----Original Message-----
From: Alex Holden
To: Henry Chea
Cc: ####@####.####
Sent: 3/13/2002 1:01 PM
Subject: Re: [nanogui] touchscreen calibration

Henry Chea wrote:
> In mou_ads.c I am editing PD_SetCalibration() because it seems there
is no
> SetCalibration() function in this file.

That's right.

>         case 5: 
>            res_x = arg; 
>            break; 

You may possibly have to set these values yourself to the display 
resolution (or it may be done by the kernel framebuffer code when the 
framebuffer size is set).

>         case 13:         /* 0 = Enable calibration ; 1 = Calibration
OK */ 
>            cal_ok = arg; 

I'm not sure what that does. Check to see what cal_ok is used for; it 
may possibly put the driver into a raw ("calibration") mode.

> Looking at this, I see no cases for "SHOULD_KERNEL_SCALE_DATA" and
> "SET_Z_THRESHOLD".  Should I remove the ioctl lines from my code that
deal
> with these two?  Also, is "MWMOUSEMODE_RAW" something I have to edit?

For SHOULD_KERNEL_SCALE_DATA what you'll need to do is put the device 
into a mode where it doesn't do any scaling on the data when the driver 
asks for MWMOUSEMODE_RAW. If there isn't any specific ioctl that can do 
that, you could set the calibration values (xmin, xmax, ymin, ymax) to 
the limits of the values supplied by the chip (IIRC, I think they are 
0-1024 in both axes).

For SET_Z_THRESHOLD, you need to find out what the third byte of the 
data packet from the kernel is. If it is a raw pressure value, (which is

what you want really so you can supply it to the client applications), 
remove the SET_Z_THRESHOLD ioctl, and modify the PD_Read() function so 
that instead of:

         if(data[2] > 0) {
                 *pb = MWBUTTON_L;
                 *pz = 100;
         } else {
                 *pb = 0;
                 *pz = 0;
         }

You have something like:

	*pz = data[2];
	if(data[2] > mousedev.zthresh) *pb = MWBUTTON_L;
	else *pb = 0;

If the kernel handles the z threshold itself and just returns a 
true/false "button is pressed"/"button is not pressed", then remove the 
SET_Z_THRESHOLD ioctl() and live with the fact that you have no way to 
calibrate the value and no way for clients to make use of the pressure 
information the device provides (or hack the kernel driver so it returns

the raw pressure information and do what I said above).

If your driver does return pressure information and you make the 
modification to set *pz properly, have a go with the "pressure" demo 
(you may need to mess with the calibration values in 
demos/nanox/pressure.c). It's a version of the classic "scribble" demo 
but with the width of the line varying depending on how hard you press- 
it's quite fun on the TuxScreen.

BTW, I personally think the scaling and filtering is all best done in 
user space anyway, like the new ucb1x00 driver.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

I have my nanoX server all setup and that is working fine.  I'm trying
to get my touch panel calibration program running, but it won't respond
to anything outside of my 320x240 window.

I saw there is some sort of SetCapture() function, but I'm using the
Nano-X commands and not the win32.  

Basically, my mouse driver is filtering out everything else and I've
already set my GdRestrictMouse to larger values.

Any ideas,

Thanks,

Gabriel

 
Gabriel Goldstein
Anidea Engineering, Inc.
Fort Lauderdale, FL
Phone:  954-254-9898
Fax:  240-368-8982
 
New Address and Web Site!
####@####.####
www.anidea-engineering.com
 
 

Hello Mark,

this program is a fine application. I will use some std. function from 
microwindows to use this transform.
But, I am going to use some more different algorithm to calculate the 
coefficients by three points.

A link about the calibration:
http://www.embedded.com/story/OEG20020529S0046

Thanks,
Daniel




> Hello Daniel,
>
> I did some more searching in Microwindows and found a nice example 
> called nxcal.c.  This program calculates a transform which is also 
> used in GdMouseRead to filter jitter.  We used nxcal.c as a starting 
> point and came up with a nice calibration and filter for our touchscreen.
>
> Thanks,
>
> Mark
>
> At 01:03 PM 3/9/2004 +0100, you wrote:
>
>> Hello Mark,
>>
>>
>> Mark Mussetter írta:
>>
>>> Hello Everyone,
>>>
>>> We have a 240X320 touchscreen display basically working with 
>>> FLTK1.1.4 and Microwindows-0.90.  We calibrated the touchscreen by 
>>> hand using equations that take into account the ADC ranges of the 
>>> X-axis and Y-axis.  This gets us pretty close on our coordinate 
>>> calculations, however, we were wondering if there is a standard way 
>>> of doing touchscreen calibration with Microwindows so we don't have 
>>> to repeat this procedure for every new screen we install.
>>
>> I am working also on calibration problem. I have not find any 
>> standard routine. That is the case I am going to write one! I have a 
>> sample program that I can send to you that maybe can partly help.
>>
>>> Is there a standard calibration routine included in Microwindows and 
>>> do you feed it raw ADC values?
>>>
>>> Also, we are getting coordinate readings back that vary by about +/- 
>>> 10 pixels of the actual "pen down" location.  Are there any 
>>> filtering routines out there that filter out that noise and maybe 
>>> debounce the "pen down" readings?
>>
>>
>> I found an old microwindows driver at this distribution at the 
>> src/drivers/old/mou_tp.c.  In the  "first"PD_Read(...) function you 
>> can find codes that filter the noises after the conversation process. 
>> I implemented this one and I got more stable cursor.
>>
>> Regards,
>> Daniel
>>
>>>
>>> Thanks for any help you could give,
>>>
>>> Mark
>>>
>>> Our system:
>>>   Motorola 5272
>>>   RTEMS 4.6.0pre5
>>>   FLTK1.1.4
>>>   nxlib0.44
>>>   Microwindows-0.90
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ####@####.####
>>> For additional commands, e-mail: ####@####.####
>>>
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>
>
>

Hello Everyone,

We have a 240X320 touchscreen display basically working with FLTK1.1.4 and 
Microwindows-0.90.  We calibrated the touchscreen by hand using equations 
that take into account the ADC ranges of the X-axis and Y-axis.  This gets 
us pretty close on our coordinate calculations, however, we were wondering 
if there is a standard way of doing touchscreen calibration with 
Microwindows so we don't have to repeat this procedure for every new screen 
we install.

Is there a standard calibration routine included in Microwindows and do you 
feed it raw ADC values?

Also, we are getting coordinate readings back that vary by about +/- 10 
pixels of the actual "pen down" location.  Are there any filtering routines 
out there that filter out that noise and maybe debounce the "pen down" 
readings?

Thanks for any help you could give,

Mark

Our system:
   Motorola 5272
   RTEMS 4.6.0pre5
   FLTK1.1.4
   nxlib0.44
   Microwindows-0.90

Hello Mark,


Mark Mussetter írta:

> Hello Everyone,
>
> We have a 240X320 touchscreen display basically working with FLTK1.1.4 
> and Microwindows-0.90.  We calibrated the touchscreen by hand using 
> equations that take into account the ADC ranges of the X-axis and 
> Y-axis.  This gets us pretty close on our coordinate calculations, 
> however, we were wondering if there is a standard way of doing 
> touchscreen calibration with Microwindows so we don't have to repeat 
> this procedure for every new screen we install.
>
I am working also on calibration problem. I have not find any standard 
routine. That is the case I am going to write one! I have a sample 
program that I can send to you that maybe can partly help.

> Is there a standard calibration routine included in Microwindows and 
> do you feed it raw ADC values?
>
> Also, we are getting coordinate readings back that vary by about +/- 
> 10 pixels of the actual "pen down" location.  Are there any filtering 
> routines out there that filter out that noise and maybe debounce the 
> "pen down" readings?

I found an old microwindows driver at this distribution at the 
src/drivers/old/mou_tp.c.  In the  "first"PD_Read(...) function you can 
find codes that filter the noises after the conversation process. I 
implemented this one and I got more stable cursor.

Regards,
Daniel

>
> Thanks for any help you could give,
>
> Mark
>
> Our system:
>   Motorola 5272
>   RTEMS 4.6.0pre5
>   FLTK1.1.4
>   nxlib0.44
>   Microwindows-0.90
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>
>
>

Hello Daniel,

I did some more searching in Microwindows and found a nice example called 
nxcal.c.  This program calculates a transform which is also used in 
GdMouseRead to filter jitter.  We used nxcal.c as a starting point and came 
up with a nice calibration and filter for our touchscreen.

Thanks,

Mark

At 01:03 PM 3/9/2004 +0100, you wrote:
>Hello Mark,
>
>
>Mark Mussetter írta:
>
>>Hello Everyone,
>>
>>We have a 240X320 touchscreen display basically working with FLTK1.1.4 
>>and Microwindows-0.90.  We calibrated the touchscreen by hand using 
>>equations that take into account the ADC ranges of the X-axis and 
>>Y-axis.  This gets us pretty close on our coordinate calculations, 
>>however, we were wondering if there is a standard way of doing 
>>touchscreen calibration with Microwindows so we don't have to repeat this 
>>procedure for every new screen we install.
>I am working also on calibration problem. I have not find any standard 
>routine. That is the case I am going to write one! I have a sample program 
>that I can send to you that maybe can partly help.
>
>>Is there a standard calibration routine included in Microwindows and do 
>>you feed it raw ADC values?
>>
>>Also, we are getting coordinate readings back that vary by about +/- 10 
>>pixels of the actual "pen down" location.  Are there any filtering 
>>routines out there that filter out that noise and maybe debounce the "pen 
>>down" readings?
>
>I found an old microwindows driver at this distribution at the 
>src/drivers/old/mou_tp.c.  In the  "first"PD_Read(...) function you can 
>find codes that filter the noises after the conversation process. I 
>implemented this one and I got more stable cursor.
>
>Regards,
>Daniel
>
>>
>>Thanks for any help you could give,
>>
>>Mark
>>
>>Our system:
>>   Motorola 5272
>>   RTEMS 4.6.0pre5
>>   FLTK1.1.4
>>   nxlib0.44
>>   Microwindows-0.90
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####