On Wed, 2005-02-09 20:51:43 +0000, Paulo Marques <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Jan-Benedict Glaw wrote: > >On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <[EMAIL PROTECTED]> > >wrote in message <[EMAIL PROTECTED]>: > >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 [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
