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

[Paulo Marques]

Jan-Benedict Glaw wrote:
> On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <pmarques@xxxxxxxxxxxx>
> wrote in message <420A518A.9040500@xxxxxxxxxxxx>:
>
> [...]
> > Touch screens doing this are severely brain-damaged. And yes, I've come 
> > across a few of them, but not lately.
>
>
> That's IMHO not brain-damaged, but pure physics: just consider scratches
> or dust (or other substances) applied to the touch foil. This happens
> all the time, so the touch screen gets out of calibration. This won't
> happen on a screen used only twice a day. But think about a touch screen
> that's tortured all the day with pencils, finger rings, dirty fingers,

The brain-damaged part wasn't the calibration. It was the calibration 
being done in the touchscreen itself, instead of letting the PC handle 
it for them. We will always need calibration, of course.

> ...
> > I would say that a tool to recover the touch screen into a "usable" 
> > state, by talking directly to the serial port, and "calibrating" it to 
> > max possible / min possible values would be the best way to deal with this.
>
>
> Min/Max values (as of protocol theory) is possibly not the very best you
> can do with the hardware. I more thing about submitting these (after
> physical calibration) to the kernel driver to supply them to it's users.

You're missing my point completely... :(

What I was suggesting was that we don't use physical calibration *at all*.

We let the touch screen send the widest range it can muster, so that we 
don't have quantization errors. We then calibrate in software as for any 
other touch screen, using the coordinates sent as "raw data".

> > Modern touchscreens just send the A/D data to the PC, and let the real 
> > processor do the math (it can even do more complex calculations, like 
> > compensate for rotation, etc.). IMHO calibration should be handled by 
> > software.
>
> Is this done eg. by Elo, Mutouch, Fujitsu, T-Sharc (to only name the
> most common)? I don't think so...

If you don't try to configure the "physical calibration" of a Elo, 
MuTouch, etc, they send coordinates in a nice 0..2^N-1 format. That is 
the best approach IMHO.

> [...]
> This only happens if you don't configurethe MSR properly :-) Most of
> them can be configured to send quite complex (as in: structured) init
> sequences that cannot be generated by a keyboard (ie multiple break
> codes without make codes and the like). 

Even if they can not be generated by a keyboard, if you don't handle 
them in special way, you'll get a lot of rubbish. We do handle the 
special sequences when available, but there still barcode scanners that 
don't generate a nice sequence.

There are even barcode scanners that generate things like <press 
Alt>+<numeric X>+<numeric Y>+<numeric Z>+<release Alt> without even 
bothering to release the numeric keys, to generate ASCII code XYZ :P

--
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/