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

[Jan-Benedict Glaw]

On Thu, 2005-02-10 13:06:46 +0000, Paulo Marques <pmarques@xxxxxxxxxxxx>
wrote in message <420B5C66.8040408@xxxxxxxxxxxx>:
> 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.

All touchscreens get calibrated once during their production AFAIK. This
should result at least in a "useable" resolution. ...but have a tight
look at today's touches: their [xy]{min,max} values don't cover all the
theoretical range of values that could be sent with the protocol in use.
Just taking an example, one screen here (it has never ever been
physically recalibrated except right after production) used values (for
X as well as for Y) in the range of about [350..3800]. The protocol does
allow a lot more...

> That's the brain-damaged part.

It's not :)  The foil layers aren't all that equal after production.
They're (from the protocol point of view) generalized by calibrating
them once (during production). However, if the screen gets injured, this
must either be re-done, or the screen may need to be replaced. However,
replacing parts in the field is expensive and service staff tries to not
do that, but instead a recalibration is tried first. IFF the touchscreen
is then found to be *really* dead, it's replaced.

> 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.

But it needs to know the exact range of possible resistance/capacity to
be able to do that. This is where the trouble starts that I'm talking
about. Of course you can *assume* that capacity will be in a
(well-known) range (you know the range because you can just test a
production example), but this range is a bit different for each
touchscreen produced, let alone the fact that the foils may get
scratches or other injuries. In a bad case, you get a near-short-circuit
so that your (new) range of values is near-zero. Recalibrating the A/D
converter may revive this almost-dead screen.

> 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.

Right, but there are two kinds of calibration:

(1) Mapping the raw capacity/resistor values (that only the TS controller
    is aware of) to something the HID API can output. (This, too, includes
    that the kernel dictates the range of values that can be reached).
(2) Mapping the range of reachable HID coordinates to actual on-screen
    pixels. (This accounts for a person't fat and/or un-even fingers...)

"Calibration" in X11 with all it's drivers is done at the (2) level. You
first have to figure out the range of generated values and then place
these as [xy]{min,max} values.

However, the hardware-internal mapping (1) isn't covered anywhere right
now. This usually isn't much of a problem during real use, but it *is* a
problem if the hardware ever gets damaged (or the controller's flash
breaks). Ever tried to use a serial sniffer on vendor's original MS
Windows drivers? They almost always update the controller's internal
mapping, too.

> 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.

This is nice, but even cannot be done with all TS controllers. The very
old ones actually just hand over the pure A/D values as a 10bit integer.
For sure, you won't ever see a touchscreen that covers the whole scale:)

> 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).

ACK. We'd do a lib for that and have a X11 driver to make use of it.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@xxxxxxxxxx    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier BÃrger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Attachment: signature.asc
Description: Digital signature