On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > >>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 [EMAIL PROTECTED] . +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));
signature.asc
Description: Digital signature
