Re: [RFC/RFT] [patch] Elo serial touchscreen driver

[Paulo Marques <pmarques@grupopie.com>]

Jan-Benedict Glaw wrote:
> On Wed, 2005-02-09 22:53:35 +0100, Vojtech Pavlik <vojtech@suse.cz>
> wrote in message <20050209215335.GA2634@ucw.cz>:
> 
>>>That cannot be done. Just hit a resistor-based touchscreen once with a
>>>hammer. You'll probably see that you need a physical recalibration
>>>then... Or flood it with water-solved citronic acid and let is on the
>>>screen for some days. That's funny, but it's real life...
>>
>>You'll need a new touchscreen most likely. The hammer will break the
>>glass if you hit it properly, and if the citric acid gets between the
>>resistive layers, you get nonlinear distortion of the resistivity and
>>that cannot be calibrated for.

Actually, if this is done in a library, we might compensate for 
non-linear distortion, by making a "high resolution" calibration where 
the user has to press a grid of 4x4 points (or something like that) 
instead of just a few of points. The grid would allow non-linear 
calibration.

I'm not suggesting that we can use a touch screen that has citric acid 
moving around between the layers, though :)

> If they were private customers, sure, they'd just buy a new touchscreen.
> But in reality, as long as it somewhat "works", it'll be used as long as
> possible.

We are seriously diverging now....

Let me try to put things into perspective:

   ---------------
  |               |                                        --------
  |  Touch        |          -----------                  |        |
  |  Screen       |---------|    TS     |   serial port   |   PC   |
  |               |       __|controller |-----------------|        |
  |               |      /  |           |                 |        |
   ---------------       |   -----------                   --------
        \_______________/

In a previous post you said:

> 		Basically all these touchscreens are capable of being
> 		calibrated. It's not done with just pushing the X/Y
> 		values the kernel receives into the Input API. These
> 		beasts may get physically mis-calibrated and eg. report
> 		things like (xmax - xmin) <= 20, so resolution would be
> 		really bad and kernel reported min/max values were only
> 		"theoretical" values, based on the protocol specs.

To get raw values that are (xmax-xmin)<=20, the TS controller must be 
"trying" to do some calibration itself.

That's the brain-damaged part.

The TS controller should not be doing any calibration at all, and send 
the widest range it can through the serial port to the PC.

On the PC we must have a library that is capable of scaling / rotating 
those values so that it converts them into "screen absolute" 
coordinates. I call these screen absolute because they shouldn't depend 
on the actual resolution.

So there is no doubt that calibration must be done. We are past that. I 
too work with touch screens in restaurants for more than 10 years now, 
so I surely know what an agrssive environment is, and what damage a 
touchscreen might be exposed to.

So, if the inputattach program initializes the TS controller to make it 
send the widest range (1:1 calibration) it can deliver, we can do all 
the calibration on the PC and not depend on the TS being able to do the 
calibration itself.

Actually a calibration that can do scaling and rotation, can 
automatically compensate for mirroring and/or switched X/Y axes. We 
probably need the user to press 4 points for that, though (3 points are 
enough, but just barely enough).

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)