nanogui: Thread: touchscreen calibration


[<<] [<] Page 2 of 3 [>] [>>]
Subject: Re: [nanogui] touchscreen calibration
From: Alex Holden ####@####.####
Date: 11 Mar 2002 16:06:22 -0000
Message-Id: <3C8CD49D.3000904@linuxhacker.org>

Jordan Crouse wrote:
> I'll bet Simon means tpcal: microwin/src/contrib/GPL/tpcal

Henry mentioned an nxcal too so I thought there must be another program 
called nxcal somewhere that I hadn't seen. Oh well, I already changed it 
to nanocal in my tree.

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

Subject: Re: [nanogui] touchscreen calibration
From: "Greg's email" ####@####.####
Date: 11 Mar 2002 16:29:09 -0000
Message-Id: <004d01c1c918$d6b70040$efa9fea9@xmission.com>

> I'll bet Simon means tpcal: microwin/src/contrib/GPL/tpcal
>
> nxcal works for me - its a good name, to the point, and similar to all
> the other nx utilities.

Jordan - did the source to nxcal ever get released with
PIXIL OE 1.0?  Perhaps this package needs to be included
with the base Microwindows distribution.  There ought to be
one standard calibration program for Microwindows.

Regards,

Greg





>
> Jordan
>
> On Mon, 2002-03-11 at 08:45, Alex Holden wrote:
> > Simon Wood wrote:
> > > If I remember correctly I think you find that the nxcal application
outputs
> > > the values for calibration to the STDOUT, these will need to be
redirected
> > > into the calibration file for the touchscreen driver (/etc/tpcal??).
> >
> > Sorry, this confusion is due to my not realising there was already a
> > progam called nxcal when I wrote my new Nano-X calibrator program. I'll
> > change the name.
> >
> > --
> > ------------ Alex Holden - http://www.linuxhacker.org ------------
> > If it doesn't work, you're not hitting it with a big enough hammer
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

Subject: Re: [nanogui] touchscreen calibration
From: Alex Holden ####@####.####
Date: 11 Mar 2002 16:37:45 -0000
Message-Id: <3C8CDBF7.20804@linuxhacker.org>

Greg's email wrote:
> Jordan - did the source to nxcal ever get released with
> PIXIL OE 1.0?  Perhaps this package needs to be included
> with the base Microwindows distribution.  There ought to be
> one standard calibration program for Microwindows.

I think it'd make sense to adapt the various touchscreen drivers to use 
the new client side calibration API and program I've written. The main 
advantage of it is that the program runs within Nano-X and should work 
with any touchscreen driver that's been adapted to use the new 
calibration API. It shouldn't be a difficult task providing you have the 
hardware to test it (the new ucb1x00 driver is the only driver which 
uses it so far because the only touchscreen device I have is the 
TuxScreen display).

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

Subject: Re: [nanogui] touchscreen calibration
From: Jordan Crouse ####@####.####
Date: 11 Mar 2002 16:57:25 -0000
Message-Id: <1015865319.18313.99.camel@cosmic>

There ought to be
> one standard calibration program for Microwindows.
> 

I agree.  It would be nice to have a single program to start out with.


Right now, the whole touchscreen world is in limbo, awaiting the
decisions of the kernel maintainers.

Recently, Richard King (the arm-linux maintainer), Alan Cox and Linus got together and decided on 
a long term plan to move all touchscreen input into the input subsystem.  
This means that all touchscreens will use a common interface like keyboards and mice.   
When that happens, then we will only need 1 calibrator anyway.  

Until that point, I think that we should use a single program that can
interface with a standard Microwindows API for calibration.  Because
calibration can differ from system to system, I wonder if we have have a
new hook in the input driver for setting calibration data (coupled with
a API function for sending the data from user land.  IIRC, Alex's
program uses something like this already).  

That way, each driver could read in standard calibration information and
do its own implementation specific calibration.  In the future, when it
all gets unified under one system, then the hooks could quietly go away.

So far, I like what Alex has done with his calibration program.  If you
had to choose a single calibration program, I would start there.

Jordan








Subject: RE: [nanogui] touchscreen calibration
From: Henry Chea ####@####.####
Date: 11 Mar 2002 18:37:53 -0000
Message-Id: <ED968F412990DE4080ADEC412897784907C6A4@gotz-fs1.semcon.se>

Ack!  Ok I'll try to clarify a little from what I know:

tpcal: comes with the microwindows package and is found in
microwin/src/contrib/GPL/tpcal  .  It is able to ask the user to tap the
touchscreen at certain points, but ultimately it does nothing more than
output seven digits to the terminal.  Actually using those seven numbers to
calibrate the touchscreen is up to the programmer to figure out.

nxcal: comes with Pixil OE.  However I was not able to get it working
properly on my platform (ADS Graphicsmaster).  My problem was that it
ignored all touchscreen inputs.

nanocal: a new calibration program made by Alex Holden.  Requires
touchscreen drivers that are adapted to use new calibration functions.


Alex, to answer your question about the ADS Graphicsmaster, yes it does use
the ucb1200 based touchscreen interface.  However, the ucb1200 interface
that is used is customized specifically for the ADS touchscreen hardware,
and thus nano-X has to use a unique touchscreen driver (mou_ads.c) specific
to my hardware.  If I try to use nano-X's ucb1x00mouse.c driver it results
in:

Error 19 opening touch panel
Cannot initialise mouse

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

In any case, I was finally able to make a crude nano-X calibration program
for my platform using ioctl to set the calibration data.

Alex, if you would like me to do more testing on my platform, I'm more than
happy to do so.  Just let me know.

Cheers,
//Henry Chea
Semcon Sweden AB

-----Original Message-----
From: Alex Holden ####@####.####
Sent: den 11 mars 2002 17:00
To: Jordan Crouse
Cc: Simon Wood; ####@####.####
Subject: Re: [nanogui] touchscreen calibration


Jordan Crouse wrote:
> I'll bet Simon means tpcal: microwin/src/contrib/GPL/tpcal

Henry mentioned an nxcal too so I thought there must be another program 
called nxcal somewhere that I hadn't seen. Oh well, I already changed it 
to nanocal in my tree.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
Subject: Re: [nanogui] touchscreen calibration
From: Alex Holden ####@####.####
Date: 11 Mar 2002 18:49:54 -0000
Message-Id: <3C8CFAEE.6000100@linuxhacker.org>

Jordan Crouse wrote:
> Right now, the whole touchscreen world is in limbo, awaiting the
> decisions of the kernel maintainers.

Remember that even after Linux moves to the new input model we'll still 
need to support touchscreen devices on older linux kernels and other 
operating systems.

> interface with a standard Microwindows API for calibration.  Because
> calibration can differ from system to system, I wonder if we have have a
> new hook in the input driver for setting calibration data (coupled with

What information do drivers need to know other than the minimum and 
maximum x and y values, whether to swap the x and/or y axes, and what 
pressure value to use as the "click" threshold? That's all included in 
the new API and calculated by the new calibrator program, as well as 
whether or not the cursor should be visible (I think that should be a 
personal user choice rather than hard wiring it into the mouse driver 
like it used to be).

> So far, I like what Alex has done with his calibration program.  If you
> had to choose a single calibration program, I would start there.

The two main things that might be nice to do with it is to improve the 
look of the widgets and to add a startup splashscreen that gets 
displayed before it does the first calibration (since it'll be the first 
thing users see when they boot their machine up for the first time). 
Those really ought to be done by someone with more artistic ability than 
me though (I can write the splashscreen loading code easily enough if 
someone decides to design a splashscreen though).

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

Subject: Re: [nanogui] touchscreen calibration
From: Jordan Crouse ####@####.####
Date: 11 Mar 2002 19:03:08 -0000
Message-Id: <1015872861.18726.204.camel@cosmic>

On Mon, 2002-03-11 at 11:43, Alex Holden wrote:
> Jordan Crouse wrote:
> > Right now, the whole touchscreen world is in limbo, awaiting the
> > decisions of the kernel maintainers.
> 
> Remember that even after Linux moves to the new input model we'll still 
> need to support touchscreen devices on older linux kernels and other 
> operating systems.

Right.  But by passing the calibration data to the drivers and letting
them deal with it, we don't have to worry about that from an engine
standpoint.

> > interface with a standard Microwindows API for calibration.  Because
> > calibration can differ from system to system, I wonder if we have have a
> > new hook in the input driver for setting calibration data (coupled with
> 
> What information do drivers need to know other than the minimum and 
> maximum x and y values, whether to swap the x and/or y axes, and what 
> pressure value to use as the "click" threshold? 

That information should be passed to the driver, but each driver will
handle its calibration a bit differently (for example, the Ipaq still
uses a kernel calibration), so the engine would be better served if it
called a: 

(driverptr)->set_calibration(minx, maxx, miny, maxy, swapx, swapy,
click) 

that would then handle any implementation specific nastiness.  But no,
the minimum and maximum X and Y values, a Z threshold and a X and Y swap
are all we need in terms of data.

The only other thing that may be nice to do is to send a GR_MOUSE_EVENT
when the calibration data is changed.  That way, programs that care can
be informed (not that I know why a program would care, but maybe it does
its own scaling or something).


Jordan


Subject: Re: [nanogui] touchscreen calibration
From: Alex Holden ####@####.####
Date: 11 Mar 2002 19:19:26 -0000
Message-Id: <3C8D01DC.902@linuxhacker.org>

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

Index: drivers/input_rtems.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/input_rtems.c,v
retrieving revision 1.3
diff -u -r1.3 input_rtems.c
--- drivers/input_rtems.c	2002/03/03 10:48:17	1.3
+++ drivers/input_rtems.c	2002/03/11 19:01:03
@@ -59,6 +59,7 @@
 	MWMou_GetDefaultAccel,	/* GetDefaultAccel */
 	MWMou_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_ads.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_ads.c,v
retrieving revision 1.4
diff -u -r1.4 mou_ads.c
--- drivers/mou_ads.c	2002/03/03 10:48:17	1.4
+++ drivers/mou_ads.c	2002/03/11 19:01:03
@@ -20,6 +20,7 @@
 static int PD_GetButtonInfo(void);
 static void PD_GetDefaultAccel(int *pscale,int *pthresh);
 static int PD_Read(MWCOORD *px, MWCOORD *py, MWCOORD *pz, int *pb);
+static void PD_SetCalibration(void);
 
 /* Mouse device functions and default calibration parameters. */
 MOUSEDEVICE mousedev = {
@@ -29,6 +30,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	PD_SetCalibration,	/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
@@ -122,6 +124,17 @@
 		return 0;			/* don't have any data   */
 	else 
 		return 2;			/* have full set of data */
+}
+
+static void PD_SetCalibration(void)
+{
+	/*
+	 * Add code here which does whatever ioctls are necessary on pd_fd
+	 * to put the device in and out of raw mode, and set the calibration
+	 * values when in cooked mode. Note that if there is no ioctl to put
+	 * the device in raw (unscaled) mode, it may be possible to use min=0
+	 * and max=1024 for both X and Y instead to get the unscaled values.
+	 */
 }
 
 #ifdef TEST
Index: drivers/mou_dos.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_dos.c,v
retrieving revision 1.3
diff -u -r1.3 mou_dos.c
--- drivers/mou_dos.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_dos.c	2002/03/11 19:01:03
@@ -31,6 +31,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	PD_Poll,		/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_dynapro.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_dynapro.c,v
retrieving revision 1.3
diff -u -r1.3 mou_dynapro.c
--- drivers/mou_dynapro.c	2002/02/21 02:43:47	1.3
+++ drivers/mou_dynapro.c	2002/03/11 19:01:03
@@ -40,6 +40,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_fbsd.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_fbsd.c,v
retrieving revision 1.3
diff -u -r1.3 mou_fbsd.c
--- drivers/mou_fbsd.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_fbsd.c	2002/03/11 19:01:03
@@ -31,6 +31,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_gpm.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_gpm.c,v
retrieving revision 1.3
diff -u -r1.3 mou_gpm.c
--- drivers/mou_gpm.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_gpm.c	2002/03/11 19:01:03
@@ -37,6 +37,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_harrier.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_harrier.c,v
retrieving revision 1.4
diff -u -r1.4 mou_harrier.c
--- drivers/mou_harrier.c	2002/03/03 10:48:17	1.4
+++ drivers/mou_harrier.c	2002/03/11 19:01:03
@@ -75,6 +75,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_ipaq.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_ipaq.c,v
retrieving revision 1.4
diff -u -r1.4 mou_ipaq.c
--- drivers/mou_ipaq.c	2002/03/03 10:48:17	1.4
+++ drivers/mou_ipaq.c	2002/03/11 19:01:03
@@ -41,6 +41,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_mt.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_mt.c,v
retrieving revision 1.3
diff -u -r1.3 mou_mt.c
--- drivers/mou_mt.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_mt.c	2002/03/11 19:01:03
@@ -30,6 +30,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_null.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_null.c,v
retrieving revision 1.2
diff -u -r1.2 mou_null.c
--- drivers/mou_null.c	2002/02/14 19:09:56	1.2
+++ drivers/mou_null.c	2002/03/11 19:01:03
@@ -24,6 +24,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	PD_Poll,		/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_ps5.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_ps5.c,v
retrieving revision 1.3
diff -u -r1.3 mou_ps5.c
--- drivers/mou_ps5.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_ps5.c	2002/03/11 19:01:03
@@ -30,6 +30,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_ser.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_ser.c,v
retrieving revision 1.4
diff -u -r1.4 mou_ser.c
--- drivers/mou_ser.c	2002/03/03 10:48:17	1.4
+++ drivers/mou_ser.c	2002/03/11 19:01:03
@@ -121,6 +121,7 @@
 #else
 	NULL,			/* Poll */
 #endif
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_tp.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_tp.c,v
retrieving revision 1.5
diff -u -r1.5 mou_tp.c
--- drivers/mou_tp.c	2002/03/03 10:48:17	1.5
+++ drivers/mou_tp.c	2002/03/11 19:01:03
@@ -68,6 +68,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_ucb1x00.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_ucb1x00.c,v
retrieving revision 1.9
diff -u -r1.9 mou_ucb1x00.c
--- drivers/mou_ucb1x00.c	2002/03/02 23:24:29	1.9
+++ drivers/mou_ucb1x00.c	2002/03/11 19:01:03
@@ -82,6 +82,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	50,			/* xmin */
 	930,			/* xmax */
Index: drivers/mou_x11.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_x11.c,v
retrieving revision 1.3
diff -u -r1.3 mou_x11.c
--- drivers/mou_x11.c	2002/03/03 10:48:17	1.3
+++ drivers/mou_x11.c	2002/03/11 19:01:03
@@ -25,6 +25,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: drivers/mou_yopy.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/drivers/mou_yopy.c,v
retrieving revision 1.4
diff -u -r1.4 mou_yopy.c
--- drivers/mou_yopy.c	2002/03/03 10:48:17	1.4
+++ drivers/mou_yopy.c	2002/03/11 19:01:03
@@ -29,6 +29,7 @@
 	PD_GetDefaultAccel,	/* GetDefaultAccel */
 	PD_Read,		/* Read */
 	NULL,			/* Poll */
+	NULL,			/* SetCalibration */
 	MWMOUSEMODE_COOKED,	/* mode */
 	0,			/* xmin */
 	0,			/* xmax */
Index: engine/devmouse.c
===================================================================
RCS file: /home/cvs/microwin-aph/src/engine/devmouse.c,v
retrieving revision 1.4
diff -u -r1.4 devmouse.c
--- engine/devmouse.c	2002/03/08 10:10:21	1.4
+++ engine/devmouse.c	2002/03/11 19:01:03
@@ -483,4 +483,6 @@
 		if(showcursor) GdShowCursor(&scrdev);
 		else GdHideCursor(&scrdev);
 	}
+	/* Inform the mouse driver that the values have changed. */
+	if(mousedev.SetCalibration) mousedev.SetCalibration();
 }
Index: include/device.h
===================================================================
RCS file: /home/cvs/microwin-aph/src/include/device.h,v
retrieving revision 1.6
diff -u -r1.6 device.h
--- include/device.h	2002/03/08 10:10:21	1.6
+++ include/device.h	2002/03/11 19:01:03
@@ -210,6 +210,7 @@
 	void	(*GetDefaultAccel)(int *pscale,int *pthresh);
 	int	(*Read)(MWCOORD *dx,MWCOORD *dy,MWCOORD *dz,int *bp);
 	int	(*Poll)(void);		/* not required if have select() */
+	void	(*SetCalibration)(void);
 	int	mode;
 	MWCOORD	xmin;
 	MWCOORD	xmax;
Subject: Re: [nanogui] touchscreen calibration
From: Alex Holden ####@####.####
Date: 11 Mar 2002 19:28:54 -0000
Message-Id: <3C8D0417.8070804@linuxhacker.org>

Jordan Crouse wrote:
> That information should be passed to the driver, but each driver will
> handle its calibration a bit differently (for example, the Ipaq still
> uses a kernel calibration), so the engine would be better served if it
> called a: 
> (driverptr)->set_calibration(minx, maxx, miny, maxy, swapx, swapy,
> click) 

I see what you mean now (there needs to be a callback to inform the 
mouse driver that the calibration has changed), and in fact only just 
added this after Henry asked how he would do it for the ADS driver and I 
realised that it needed to know when the values had changed in order to 
tell the kernel.

> The only other thing that may be nice to do is to send a GR_MOUSE_EVENT
> when the calibration data is changed.  That way, programs that care can
> be informed (not that I know why a program would care, but maybe it does
> its own scaling or something).

I disagree. The only value which it might be useful for a client program 
  other than the calibrator itself to know is the Z threshold, for those 
which make use of the pressure sensing information. It could be argued 
that they're better off having their own pressure calibration facility 
anyway though. The scaling values themselves are irrelevant to ordinary 
client programs because they only ever see screen coordinates.

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

Subject: RE: [nanogui] touchscreen calibration
From: Narasimha Reddy K ####@####.####
Date: 12 Mar 2002 04:19:46 -0000
Message-Id: <5575473D4532D411BE4C009027E8C838068E6681@MASBLREXC02>

Please help on building the XServer and Xlib source on Windows. Otherthan
normal building using NAMKE utility.
After building, what is the way of communication between Xlib and XServer.


rgs,

N Reddy


-----Original Message-----
From: Alex Holden ####@####.####
Sent: Tuesday, March 12, 2002 12:53 AM
To: Jordan Crouse
Cc: Greg's email; Jason Kingan; ####@####.####
Subject: Re: [nanogui] touchscreen calibration


Jordan Crouse wrote:
> That information should be passed to the driver, but each driver will
> handle its calibration a bit differently (for example, the Ipaq still
> uses a kernel calibration), so the engine would be better served if it
> called a: 
> (driverptr)->set_calibration(minx, maxx, miny, maxy, swapx, swapy,
> click) 

I see what you mean now (there needs to be a callback to inform the 
mouse driver that the calibration has changed), and in fact only just 
added this after Henry asked how he would do it for the ADS driver and I 
realised that it needed to know when the values had changed in order to 
tell the kernel.

> The only other thing that may be nice to do is to send a GR_MOUSE_EVENT
> when the calibration data is changed.  That way, programs that care can
> be informed (not that I know why a program would care, but maybe it does
> its own scaling or something).

I disagree. The only value which it might be useful for a client program 
  other than the calibrator itself to know is the Z threshold, for those 
which make use of the pressure sensing information. It could be argued 
that they're better off having their own pressure calibration facility 
anyway though. The scaling values themselves are irrelevant to ordinary 
client programs because they only ever see screen coordinates.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####


DISCLAIMER: Information contained and transmitted by this E-MAIL is
proprietary to MASCOT SYSTEMS LTD and is intended for use only by the
individual or entity to which it is addressed, and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law. If this is a forwarded message, the content of this E-MAIL may not have
been sent with the authority of the Company. If you are not the intended
recipient, an agent of the intended recipient or a person responsible for
delivering the information to the named recipient, you are notified that any
use, distribution, transmission, printing, copying or dissemination of this
information in any way or in any manner is strictly prohibited. If you have
received this communication in error, please delete this mail & notify us
immediately at ####@####.#### Before opening attachments,
please scan for viruses


[<<] [<] Page 2 of 3 [>] [>>]


Powered by ezmlm-browse 0.20.