I've written a driver for probably the most common touchscreen type - the serial Elo touchscreen. The driver should handle all generations of serial Elos, as it handles Elo 10-byte, 6-byte, 4-byte and 3-byte protocols. I do not have any touchscreen, so I can't test the driver myself.
So if you have the time, please comment on the code of the patch, and if you have an Elo, please try the driver with it. Patch attached, also attached is an uptodate version of inputattach, a program needed to get the kernel to talk to the device. Vojtech Pavlik SuSE Labs, SuSE CR Dmitry Torokhov 08:57. On Tue, 8 Feb 2005 17:42:27 +0100, Vojtech Pavlik wrote: Hi! I've written a driver for probably the most common touchscreen type - the serial Elo touchscreen. Hi, Looks very nice, unfortunately I don;t have a touchscreen to test it.
One thing - now that kcalloc in the mainline I find myself using it more and more instead of kmalloc + memtest. Dmitry - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Paulo Marques 05:29. Vojtech Pavlik wrote: Hi!
I've written a driver for probably the most common touchscreen type - the serial Elo touchscreen. If we are serious about getting support for serial touchscreens into the kernel, I can certainly give a hand there.
I work for a company that develops software for restaurants, and we have a Linux port of our main application running in actual restaurants with a custom made Linux distribution for about 2 years now. We had to support a number of touchscreens, and we do it in the application itself, reading the serial port and processing the data. If this could go into the kernel, then our application needed only to read the input device, and handle events, no matter what touch screen was there. That would be a great improvement:) The driver should handle all generations of serial Elos, as it handles Elo 10-byte, 6-byte, 4-byte and 3-byte protocols.
I do not have any touchscreen, so I can't test the driver myself. I have one that uses the 10 byte protocol (I've never seen one ELOtouch that used one of the other protocols). I can give you some feedback as soon as I have some time to test it. So if you have the time, please comment on the code of the patchand if you have an Elo, please try the driver with it. + case 9: + if (elo-csum) + inputregs(dev, regs); + inputreportabs(dev, ABSX, (elo-data4 data3); + inputreportabs(dev, ABSY, (elo-data6 data5); + inputreportabs(dev, ABSPRESSURE, (elo-data8 data7); + inputreportkey(dev, BTNTOUCH, elo-data8 elo-data7); This one is weird.
In my code I have this: button = ((buf2 & 0x03)!= 0); So maybe, ELO touchscreens that don't have pressure sense output, only send 'touch down / up' information on the 2 LSB's of the third byte(?) Anyway, inputattach should have a command line option to set the baudrate manually, as some of these touchscreens have configurable baudrates, and some POS manufacturers set them to non-default values. Also, I've already seen touchscreens where the POS manufacturer got the pin-out wrong (or something like that) so the touch reports the X coordinate where the Y should be, and vice-versa. I really don't know where this should be handled (driver, input layer, application?), but it must be handled somewhere for the applications to work. Paulo Marques - All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Vojtech Pavlik 09:00. On Wed, Feb 09, 2005 at 01:23:27PM +0000, Paulo Marques wrote: Vojtech Pavlik wrote: Hi! I've written a driver for probably the most common touchscreen type - the serial Elo touchscreen. If we are serious about getting support for serial touchscreens into the kernel, I can certainly give a hand there. I want serious support for ALL touchscreens in Linux. I work for a company that develops software for restaurants, and we have a Linux port of our main application running in actual restaurants with a custom made Linux distribution for about 2 years now.
We had to support a number of touchscreens, and we do it in the application itself, reading the serial port and processing the data. If this could go into the kernel, then our application needed only to read the input device, and handle events, no matter what touch screen was there. That would be a great improvement:) And I'm glad there is interest.:) I have one that uses the 10 byte protocol (I've never seen one ELOtouch that used one of the other protocols).
I can give you some feedback as soon as I have some time to test it. + case 9: + if (elo-csum) + inputregs(dev, regs); + inputreportabs(dev, ABSX, (elo-data4 data3); + inputreportabs(dev, ABSY, (elo-data6 data5); + inputreportabs(dev, ABSPRESSURE, (elo-data8 data7); + inputreportkey(dev, BTNTOUCH, elo-data8 elo-data7); This one is weird. In my code I have this: button = ((buf2 & 0x03)!= 0); My documentation doesn't seem to say anything about the Status (buf2) byte. If a touch bit is reported there, then great, I'll change the driver to use that.
Right now the driver uses the Z value to tell if the screen is touched or not. So maybe, ELO touchscreens that don't have pressure sense output, only send 'touch down / up' information on the 2 LSB's of the third byte(?) That's very likely. Anyway, inputattach should have a command line option to set the baudrate manually, as some of these touchscreens have configurable baudrates, and some POS manufacturers set them to non-default values. That's rather easy to do.
Also, I've already seen touchscreens where the POS manufacturer got the pin-out wrong (or something like that) so the touch reports the X coordinate where the Y should be, and vice-versa. I really don't know where this should be handled (driver, input layer, application?), but it must be handled somewhere for the applications to work. I think the best place would be in the X event driver, if X is used, or the graphics toolkit, and worst case the application. I don't believe the mirroring/flipping is kernel's job, since it tries to always pass the data with the least amount of transformation applied to achieve hardware abstraction.
Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Jan-Benedict Glaw 09:16. On Wed, 2005-02-09 18:00:15 +0100, Vojtech Pavlik wrote in message: On Wed, Feb 09, 2005 at 01:23:27PM +0000, Paulo Marques wrote: Vojtech Pavlik wrote: Hi! I've written a driver for probably the most common touchscreen type - the serial Elo touchscreen.
If we are serious about getting support for serial touchscreens into the kernel, I can certainly give a hand there. I want serious support for ALL touchscreens in Linux. Maybe I'd write drivers for the T-Sharc and fujitsu controllers, too. These are in a lot of POS hardware, too, and sometimes they're a pain to use (esp. Linux at the Point Of Sale is quite well running (I'm employed at a POS software company). And I'm glad there is interest.:) If I find a minute, I'll possibly give it a test run.
I've got actual hardware around. Also, I've already seen touchscreens where the POS manufacturer got the pin-out wrong (or something like that) so the touch reports the X coordinate where the Y should be, and vice-versa. I really don't know where this should be handled (driver, input layer, application?), but it must be handled somewhere for the applications to work.
I think the best place would be in the X event driver, if X is used, or the graphics toolkit, and worst case the application. First of all, we need a really properly working Linux event driver in XFree86/X.Org. I'm not sure if this is already the case. I don't believe the mirroring/flipping is kernel's job, since it tries to always pass the data with the least amount of transformation applied to achieve hardware abstraction. Should be handled by XFree86's driver. 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. Freefall tournament hacked play.
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). On Wed, Feb 09, 2005 at 06:14:38PM +0100, Jan-Benedict Glaw wrote: I want serious support for ALL touchscreens in Linux. Maybe I'd write drivers for the T-Sharc and fujitsu controllers, too. These are in a lot of POS hardware, too, and sometimes they're a pain to use (esp. Well, if you write them, send them my way.:) If I find a minute, I'll possibly give it a test run.
I've got actual hardware around. Also, I've already seen touchscreens where the POS manufacturer got the pin-out wrong (or something like that) so the touch reports the X coordinate where the Y should be, and vice-versa. I really don't know where this should be handled (driver, input layer, application?), but it must be handled somewhere for the applications to work. I think the best place would be in the X event driver, if X is used, or the graphics toolkit, and worst case the application.
First of all, we need a really properly working Linux event driver in XFree86/X.Org. I'm not sure if this is already the case. There is 'evtouch'. It's probably not perfect, but a good start. I don't believe the mirroring/flipping is kernel's job, since it tries to always pass the data with the least amount of transformation applied to achieve hardware abstraction.
Should be handled by XFree86's driver. 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) 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. How would the program communicate with the devices?
- 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 contentsswitch 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. This is usually 'solved' with a little patch that allows userspace to write to the keyboard (/dev/psaux like)but this is a bad hack (just look at the patches floating around for this.). Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Paulo Marques 10:12.
Vojtech Pavlik wrote: On Wed, Feb 09, 2005 at 06:14:38PM +0100, Jan-Benedict Glaw wrote: I want serious support for ALL touchscreens in Linux. I'm glad to hear it. I was just pointing out the 'serial' part, because, unlike USB and other interfaces, a serial port can not say 'what' is attached to it, so we need the 'inputattach' method to explain to the kernel what is there (and the irattach, pppd, etc.). Maybe I'd write drivers for the T-Sharc and fujitsu controllers, too. These are in a lot of POS hardware, too, and sometimes they're a pain to use (esp. Well, if you write them, send them my way.:) I sometimes feel that we should have a 'generic' touch screen driver from looking at the code for the different brands. Almost all touch screen data goes something like this: - every packet is fixed size, N bytes long - the 'header' bytes can be described by AND something expected - the X,Y,pressure,touch data can be described as 'starting at bit B, length N, multiply by Z'.
An array of these tokens should be able to handle coordinates broken into several. If this information could be passed as a module parameter, new touchscreens could be supported without any kernel modification.
We could parse a definition 'string', like this: 'SIZE:10,SYNC:0:8:85,SYNC:8:8:54,X:24:8:1,X:32:8:256,Y:40:8:1,Y:48:8:256,T:16:2:1' This string defines the touch driver for elotouch, 10 bytes packet (I didn't include the pressure reading, for simplification). I currently have 6 different 'drivers' that would all fit into this model. The same goes for all 3 elotouch protocols that you implemented.
Does this sound like a good idea? If I find a minute, I'll possibly give it a test run. I've got actual hardware around. Thanks!. I don't believe the mirroring/flipping is kernel's job, since it tries to always pass the data with the least amount of transformation applied to achieve hardware abstraction. This is one argument that I don't quite understand.
Doesn't hardware abstraction mean that the application should receive the 'same' data regardless of the hardware. I would say that the kernel would do a good job in abstracting hardware, if it always returned X,Y coordinates from 0.65535 (or something like that) in always the same direction, regardless of the actual hardware involved. Should be handled by XFree86's driver. Unfortunately, I don't use any X driver (The application runs over the framebuffer), and I don't think it is a good idea to force people to use it. 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) 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. Touch screens doing this are severely brain-damaged. And yes, I've come across a few of them, but not lately. 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. 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.
- 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 contentsswitch 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. 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 - Paulo Marques - All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Vojtech Pavlik 11:19. On Wed, Feb 09, 2005 at 06:08:10PM +0000, Paulo Marques wrote: I want serious support for ALL touchscreens in Linux.
I'm glad to hear it. I was just pointing out the 'serial' part, becauseunlike USB and other interfaces, a serial port can not say 'what' is attached to it, so we need the 'inputattach' method to explain to the kernel what is there (and the irattach, pppd, etc.). Touchscreens are one class of devices where the serial attachment is not dying. Maybe I'd write drivers for the T-Sharc and fujitsu controllers, too. These are in a lot of POS hardware, too, and sometimes they're a pain to use (esp. Well, if you write them, send them my way.:) I sometimes feel that we should have a 'generic' touch screen driver from looking at the code for the different brands.
Almost all touch screen data goes something like this: - every packet is fixed size, N bytes long - the 'header' bytes can be described by AND something expected - the X,Y,pressure,touch data can be described as 'starting at bit Blength N, multiply by Z'. An array of these tokens should be able to handle coordinates broken into several. If this information could be passed as a module parameter, new touchscreens could be supported without any kernel modification. We could parse a definition 'string', like this: 'SIZE:10,SYNC:0:8:85,SYNC:8:8:54,X:24:8:1,X:32:8:256,Y:40:8:1,Y:48:8:256,T:16:2:1' This string defines the touch driver for elotouch, 10 bytes packet (I didn't include the pressure reading, for simplification).
I currently have 6 different 'drivers' that would all fit into this model. The same goes for all 3 elotouch protocols that you implemented. Does this sound like a good idea? I don't think so.
I don't think the saving of code is worth the obfuscation, after all, 6 drivers is still not so much. Also, direct code implementation can implement better synchronization methods and faster resynchronization in case of lost bytes. And then there are protocols like the Gunze one, which wouldn't be covered by this. I don't believe the mirroring/flipping is kernel's job, since it tries to always pass the data with the least amount of transformation applied to achieve hardware abstraction.
This is one argument that I don't quite understand. Doesn't hardware abstraction mean that the application should receive the 'same' data regardless of the hardware. I would say that the kernel would do a good job in abstracting hardwareif it always returned X,Y coordinates from 0.65535 (or something like that) in always the same direction, regardless of the actual hardware involved. I can understand that, however, when the only difference is in the actual mounting of the hardware. I'm not so sure. Should be handled by XFree86's driver.
Unfortunately, I don't use any X driver (The application runs over the framebuffer), and I don't think it is a good idea to force people to use it. We could have a library that would do that and link applications against it. It could also handle things like tap-n-drag, etc, something we certainly don't want in the kernel. 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) 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.
Touch screens doing this are severely brain-damaged. And yes, I've come across a few of them, but not lately. 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. 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. And this is something the kernel certainly won't do.
Floating point math is possible in the kernel with some jumping through hoops, but avoiding it is usually the better option. 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. In that case I'm not sure if the kernel should care at all what the data is. 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.
Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Paulo Marques 11:55. Vojtech Pavlik wrote: On Wed, Feb 09, 2005 at 06:08:10PM +0000, Paulo Marques wrote:.
Touchscreens are one class of devices where the serial attachment is not dying. We could parse a definition 'string', like this: 'SIZE:10,SYNC:0:8:85,SYNC:8:8:54,X:24:8:1,X:32:8:256,Y:40:8:1,Y:48:8:256,T:16:2:1' This string defines the touch driver for elotouch, 10 bytes packet (I didn't include the pressure reading, for simplification). I currently have 6 different 'drivers' that would all fit into this model.
The same goes for all 3 elotouch protocols that you implemented. Does this sound like a good idea? I don't think so. I don't think the saving of code is worth the obfuscation, after all, 6 drivers is still not so much.
Also, direct code implementation can implement better synchronization methods and faster resynchronization in case of lost bytes. A touch screen driver is pretty small already. The only advantage would actually be to support new touchscreens without actually changing the kernel, but if we write the code for the touchscreens we already know, we will probably not see that many 'new' touchscreens with weird protocols. And then there are protocols like the Gunze one, which wouldn't be covered by this. Actually the string for the gunze touchscreen would be something like (constructed from interpreting the gunze.c source code): 'SIZE:11, SYNC:0:5:80,SYNC:40:8:44,SYNC:80:8:13, X:12:4:1000,X:20:4:100,X:28:4:10,X:36:4:1, Y:52:4:3000,Y:60:4:300,Y:68:4:30,Y:76:4:3, T:2:1:1' Yes, it doesn't look good;) And I agree that we would probably not be able to cover all touchscreens.
We could have a library that would do that and link applications against it. It could also handle things like tap-n-drag, etc, something we certainly don't want in the kernel. I really like this idea:) A libtouch library that handled calibration (this includes mirroring and swapping the coordinates) and other goodies (like filtering out short 'touch release' events while dragging, etc.) would be a good standard interface for all applications. Being in user space would also mean that the library could do things like keeping a /etc/touch.conf file where it would read default calibration data, etc. 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.
This certainly seems like a good place for it, yes. 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. And this is something the kernel certainly won't do.
Floating point math is possible in the kernel with some jumping through hoops, but avoiding it is usually the better option. We don't necessarily need floating point (even with 32 bits we have plenty of space for fixed point arithmetic), but I agree that this would be better handled in a library. Paulo Marques - All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Jan-Benedict Glaw 12:01.
On Wed, Feb 09, 2005 at 09:03:51PM +0100, Jan-Benedict Glaw wrote: 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 levelsince POS keyboards may send quite a lot more than make/break codes in 'proper' order.
I'll need some specific examples of protocols the keyboard use to judge how to tackle that. 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:-) - Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Paulo Marques 12:54. Jan-Benedict Glaw wrote: On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques wrote in message:. 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, 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. 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.
You're missing my point completely.:( What I was suggesting was that we don't use physical calibration.at all. 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'. 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. 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 without even bothering to release the numeric keys, to generate ASCII code XYZ:P - Paulo Marques - All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Jan-Benedict Glaw 13:43. On Wed, Feb 09, 2005 at 10:39:30PM +0100, Jan-Benedict Glaw wrote: On Wed, 2005-02-09 20:51:43 +0000, Paulo Marques wrote in message: Jan-Benedict Glaw wrote: On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques wrote in message: 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 fingersThe 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. Both 4-wire and 5-wire resistive touchscreens work as voltage dividers. Thus the chip doesn't have to care about the total resistance, it just applies voltage on two wires and the voltage on the other two corresponds proportionally to the position.
That's one axis measurement. For the other axis, the role of the wires is simply swapped. For capacitive touch sensors it's very much different, and the controller usually is matched to the sensor, since the sensor usually has several electrodes, so the controller 'knows' about the sensor because they were manufactured together. Regarding surface wave sensors, I'm not completely sure about the need of calibration to get the range there. I'd assume that since they measure wave reflections from reflector fins, and they know the number of the fins ( number of reflections), that they'll be able to stretch the range properly as well.
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. You'll need a new touchscreen most likely. The hammer will break the glass if you hit it properly, and if the citric acid gets between the resistive layers, you get nonlinear distortion of the resistivity and that cannot be calibrated for. Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ at Jan-Benedict Glaw 13:55. Jan-Benedict Glaw wrote: On Wed, 2005-02-09 22:53:35 +0100, Vojtech Pavlik wrote in message: 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. You'll need a new touchscreen most likely. The hammer will break the glass if you hit it properly, and if the citric acid gets between the resistive layers, you get nonlinear distortion of the resistivity and that cannot be calibrated for.
Actually, if this is done in a library, we might compensate for non-linear distortion, by making a 'high resolution' calibration where the user has to press a grid of 4x4 points (or something like that) instead of just a few of points. The grid would allow non-linear calibration. I'm not suggesting that we can use a touch screen that has citric acid moving around between the layers, though:) If they were private customers, sure, they'd just buy a new touchscreen. But in reality, as long as it somewhat 'works', it'll be used as long as possible. We are seriously diverging now.
Let me try to put things into perspective: - - Touch - Screen - TS serial port PC controller - / - - - / In a previous post you said: 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) really bad and kernel reported min/max values were only 'theoretical' values, based on the protocol specs. To get raw values that are (xmax-xmin). On Thu, Feb 10, 2005 at 03:35:28PM +0000, Paulo Marques wrote: By the way, this has nothing to do with the kernel. The input API can deliver at least 16 bit resolution to user space, so there is no limitation on the software side.
It is the A/D resolution that matters. Make that 32-bit.
Actually a calibration that can do scaling and rotation, can automatically compensate for mirroring and/or switched X/Y axes. We probably need the user to press 4 points for that, though (3 points are enough, but just barely enough). We'd do a lib for that and have a X11 driver to make use of it. Remember that the X driver will have to either link statically or the lib will have to be an X module. X drivers are not allowed to use OS libs. Ok, lets start working on it then:) Keep that enthusiasm!;) - Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line 'unsubscribe linux-kernel' in the body of a message to More majordomo info at Please read the FAQ.
Patch Fix Keyboard Rf Online
2011-12-25 13:48 Posted by what if i dont have a reinforcement,can i use this patch? 2012-01-27 10:33 Posted by I 've one big problem after this update, The enemy AI stops shooting after 3 minutes playing. I've never seen this before. I also tried it without addons but it still doesn't work. 2012-02-23 08:34 Posted by Yeah, same question, can I use this patch if I don't have Reinforcements.
2012-05-19 12:19 Posted by Richchad do you have ArmA 2 Opeartion Arrowhead? If yes, you can use this patch 2013-01-17 22:26 Posted by If download it but its says erro 0x. What sould do? 2013-06-10 17:53 Posted by i cant open the folder it says The Compressed(zipped)Folder 'C/USERS/1/DOWNLOADS/ARMA21.60COUpdate.ZIP' IS INVALID what do i do 2013-12-01 15:15 Posted by Why not delete the older patches? I have just wasted expensive MB download allocation, downloading each patch.
Why not Just in big letters which one is to update to latest from original instal? One ends up downloading the same stuff over and over. I am not the biggest expert on this kind of thing, been away a couple of years from ARMA, and now find myself shot of MB allocation. Is it just me being a miserable old git, or do I have a valid point?
Anyway.thanks for the site.at least that is something reliable. 2013-12-06 00:18 Posted by When you read the installation notes you will see some older patches might be required before you are able to install this patch. We prefer to leave all old patches available for the users as we never know which version they might have bought in time and which route they wish to go with patching.
You could always ask for some assistance in the forums when not sure. Arma 2: CO / OA / Reinforcements Patch 1.60 by Bohemia Interactive Studio Copyright (c) 2009 Bohemia Interactive. All rights reserved. Description: This update is for all Arma 2: Combined Operations / Operation Arrowhead / Reinforcements 1.50-1.60. This is the official update for Arma 2: Combined Operations / Operation Arrowhead / Reinforcements from 1.50 to 1.60.
This free update is sponsored by Sprocket, the online store where you can buy all Arma 2 series titles and other games directly from the developers. Installation: - Run the patch exe to apply the patch setup automatically. It will install all content of the patch to the folder with your Arma 2: Operation Arrowhead installation. Please note that it is not possible to rollback to a previous version after the installation of this patch, only a full reinstall of the game is possible, - if you want to keep your previous version you may want to backup the entire game installation folder before applying this patch. NOTE: This patch will also update your:. ARMA 2 1.05 to 1.11.
Patch Fix Keyboard Rf Ps
(note: ARMA 2 version 1.00-1.04 must first use patch 1.0x to 1.05). ARMA 2 BAF 1.00 to 1.03 if necessary. ARMA 2 PMC 1.00 to 1.02 if necessary. BattlEye within ARMA 2, ARMA 2: OA, ARMA 2: RFT to actual revision Highlights:. New features: FXAA Anti-Aliasing mode, user-definable memory allocators, new scripting commands, new commandline options. Multiplayer is much smoother, no more warping, includes number of fixes, optimizations and improvements.
Netcode, VON and dedicated server fixes plus configuration additions in place. Singleplayer received visual states smoothing and prediction (notable e.g.