Microtouch driver issue

bridged with qdn.public.ddk.input
Post Reply
Doug Hill

Microtouch driver issue

Post by Doug Hill » Thu Nov 06, 2003 3:17 am

The Microtouch touch screens have been built historically with the
connection point at either the 3 o'clock or 9 o'clock positions making pin
one of the connector cable either the upper right or lower left quadrant
depending upon touch screen orientation. The driver would only have to
translate the X coordinate into either X or -X and the Y to either Y or -Y
based on the orientation of the screen determined during the calibration
process.

3M recently began manufacturing screens that position the connection point
at the 12 o'clock position making pin one of the connector cable associate
with the upper left quadrant. This forces the driver to expand its
capabilities to translate the raw X value into the Y coordinate and vice
versa.

Has anyone else run across this issue with the new 3M Microtouch screens,
and if so, is there a simple resolution. Currently we are swapping the pins
around in a touch screen extender cable to logically rotate the screen by 90
degrees. This introduces some other issues that we would like to avoid
(like not being able to use the factory linearization coefficients).

Thanks in advance for any suggestions.

Alex Chapiro

Re: Microtouch driver issue

Post by Alex Chapiro » Thu Nov 06, 2003 1:44 pm

I think you can swap x and y coordinates just replacing last element in
calib file from 0 to 1.

Doug Hill wrote:
The Microtouch touch screens have been built historically with the
connection point at either the 3 o'clock or 9 o'clock positions making pin
one of the connector cable either the upper right or lower left quadrant
depending upon touch screen orientation. The driver would only have to
translate the X coordinate into either X or -X and the Y to either Y or -Y
based on the orientation of the screen determined during the calibration
process.

3M recently began manufacturing screens that position the connection point
at the 12 o'clock position making pin one of the connector cable associate
with the upper left quadrant. This forces the driver to expand its
capabilities to translate the raw X value into the Y coordinate and vice
versa.

Has anyone else run across this issue with the new 3M Microtouch screens,
and if so, is there a simple resolution. Currently we are swapping the pins
around in a touch screen extender cable to logically rotate the screen by 90
degrees. This introduces some other issues that we would like to avoid
(like not being able to use the factory linearization coefficients).

Thanks in advance for any suggestions.


Doug Hill

Re: Microtouch driver issue

Post by Doug Hill » Thu Nov 06, 2003 7:05 pm

Thank you for the suggestion. I'll have a system here from the field to
experiment with tomorrow. Do you have anything that you could send me that
defines the file structure of the Calib file or point me to the right doc
file?

Thanks


"Alex Chapiro" <achapiro@qnx.com> wrote in message
news:bodi5r$r8e$1@inn.qnx.com...
I think you can swap x and y coordinates just replacing last element in
calib file from 0 to 1.

Doug Hill wrote:
The Microtouch touch screens have been built historically with the
connection point at either the 3 o'clock or 9 o'clock positions making
pin
one of the connector cable either the upper right or lower left quadrant
depending upon touch screen orientation. The driver would only have to
translate the X coordinate into either X or -X and the Y to either Y
or -Y
based on the orientation of the screen determined during the calibration
process.

3M recently began manufacturing screens that position the connection
point
at the 12 o'clock position making pin one of the connector cable
associate
with the upper left quadrant. This forces the driver to expand its
capabilities to translate the raw X value into the Y coordinate and vice
versa.

Has anyone else run across this issue with the new 3M Microtouch
screens,
and if so, is there a simple resolution. Currently we are swapping the
pins
around in a touch screen extender cable to logically rotate the screen
by 90
degrees. This introduces some other issues that we would like to avoid
(like not being able to use the factory linearization coefficients).

Thanks in advance for any suggestions.


Alex Chapiro

Re: Microtouch driver issue

Post by Alex Chapiro » Thu Nov 06, 2003 7:10 pm

See QNX Help, DDK documentation, Input Devices, Writing an Input Device
Driver document.


Doug Hill wrote:
Thank you for the suggestion. I'll have a system here from the field to
experiment with tomorrow. Do you have anything that you could send me that
defines the file structure of the Calib file or point me to the right doc
file?

Thanks


"Alex Chapiro" <achapiro@qnx.com> wrote in message
news:bodi5r$r8e$1@inn.qnx.com...

I think you can swap x and y coordinates just replacing last element in
calib file from 0 to 1.

Doug Hill wrote:

The Microtouch touch screens have been built historically with the
connection point at either the 3 o'clock or 9 o'clock positions making

pin

one of the connector cable either the upper right or lower left quadrant
depending upon touch screen orientation. The driver would only have to
translate the X coordinate into either X or -X and the Y to either Y

or -Y

based on the orientation of the screen determined during the calibration
process.

3M recently began manufacturing screens that position the connection

point

at the 12 o'clock position making pin one of the connector cable

associate

with the upper left quadrant. This forces the driver to expand its
capabilities to translate the raw X value into the Y coordinate and vice
versa.

Has anyone else run across this issue with the new 3M Microtouch

screens,

and if so, is there a simple resolution. Currently we are swapping the

pins

around in a touch screen extender cable to logically rotate the screen

by 90

degrees. This introduces some other issues that we would like to avoid
(like not being able to use the factory linearization coefficients).

Thanks in advance for any suggestions.





Post Reply

Return to “qdn.public.ddk.input”