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

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]

On Wed, 2005-02-09 20:51:43 +0000, Paulo Marques <pmarques@grupopie.com>
wrote in message <420A77DF.6040108@grupopie.com>:
> 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>:
> >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.

Again, you cannot map 0..\inf Ohm or 0..\inf nF to a given set
[0..0xffff] of coordinates. The physical characteristics of touchscreens
*can* change, so you need to recalibrate the A/D converter itself.

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

But there *needs* to be a way to do that. I don't want to place this
functionality into the kernel, but we need to have a program for that at
some time. Current solutions are bad hacks and don't actually work
reliably.

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

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

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

It is -- as long as the physical characteristics don't change all that
much. Unfortunately (at least for real-life POS usage) this happens
frequently.

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

Which then either needs to be parsed by userspace (which needs access to
raw make/break codes and be able to send data to the kbd) or we write
keyboard-specific Input API drivers for them.

However, a userspace library for that (if raw access to the keyboard is
given) could do the same job.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]