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

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

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

On Wed, 2005-02-09 20:18:17 +0100, Vojtech Pavlik <vojtech@suse.cz>
wrote in message <20050209191817.GA1534@ucw.cz>:
> > 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.
> 
> I agree with that. It could possibly even be put into the inputattach
> init routine for the specific touchscreen.

At least, inputattach should only recalibrate if asked for that. POS
*users* are not very computer-skilled (typically, at least over here)
and even automated recalibration (ie. the cashier software forces it
because it detects that the user presses besides the actual images) are
kind of stress to them...

> > 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.
> 
> In that case I'm not sure if the kernel should care at all what the data
> is.

The problematic part is that this needs to be done at a quite low level,
since POS keyboards may send quite a lot more than make/break codes in
"proper" order...

> > What we've done in our application is to use the timings and sequence of 
> > key presses to distinguish between normal key presses and MSR data :P
> 
> Yes, embedded and single purpose systems are often full of hacks like
> this.

...and especially this problem can be better solved by reprogramming the
MCR readers :-)

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