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

[Jan-Benedict Glaw]

On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <pmarques@xxxxxxxxxxxx>
wrote in message <420A518A.9040500@xxxxxxxxxxxx>:
> >>Additionally, there are two other things that need to be addressed (and
> >>I'm willing to actually write code for this, but need input from other
> >>parties, too:)
> >>
> >>	- Touchscreen calibration
> >>		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.
> >>		I think about a simple X11 program for this. Comments?
> 
> 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,
...

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

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

> >>	- POS keyboards
> >>		These are real beasties. Next to LEDs and keycaps, they
> >>		can contain barcode scanners, magnetic card readers and
> >>		displays. Right now, there's no good API to pass
> >>		something as complex as "three-track magnetic stripe
> >>		data" or a whole scanned EAN barcode. Also, some
> >>		keyboards can be written to (change display contents,
> >>		switch on/off scanners, ...).
> >
> >
> >We probably don't want magnetic stripe data to go through the input
> >event stream (although it is possible to do that), so a new interface
> >would be most likely necessary.
> 
> It's even worse. Most keyboards don't separate the real keys from 
> magnetic stripe reader events, and just simulate key presses for MSR 
> data. They expect the software to be in a state where it is waiting for 
> that data, and will process it accordingly.

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

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