lkml.org 
[lkml]   [2005]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/RFT] [patch] Elo serial touchscreen driver
Jan-Benedict Glaw wrote:
> On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <pmarques@grupopie.com>
> wrote in message <420A518A.9040500@grupopie.com>:
>
>[...]
>>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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.182 / U:7.200 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site