Hi!
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
On Tue, 8 Feb 2005 17:42:27 +0100, Vojtech Pavlik <[email protected]> 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
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 patch,
> and if you have an Elo, please try the driver with it.
>
> [...]
> + case 9:
> + if (elo->csum) {
> + input_regs(dev, regs);
> + input_report_abs(dev, ABS_X, (elo->data[4] << 8) | elo->data[3]);
> + input_report_abs(dev, ABS_Y, (elo->data[6] << 8) | elo->data[5]);
> + input_report_abs(dev, ABS_PRESSURE, (elo->data[8] << 8) | elo->data[7]);
> + input_report_key(dev, BTN_TOUCH, elo->data[8] || elo->data[7]);
This one is weird. In my code I have this:
> button = ((buf[2] & 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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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) {
> >+ input_regs(dev, regs);
> >+ input_report_abs(dev, ABS_X, (elo->data[4] << 8) | elo->data[3]);
> >+ input_report_abs(dev, ABS_Y, (elo->data[6] << 8) | elo->data[5]);
> >+ input_report_abs(dev, ABS_PRESSURE, (elo->data[8] << 8) | elo->data[7]);
> >+ input_report_key(dev, BTN_TOUCH, elo->data[8] || elo->data[7]);
>
> This one is weird. In my code I have this:
>
> > button = ((buf[2] & 0x03) != 0);
My documentation doesn't seem to say anything about the Status (buf[2])
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
On Wed, 2005-02-09 18:00:15 +0100, Vojtech Pavlik <[email protected]>
wrote in message <[email protected]>:
> 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. calibration).
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.
ACK. 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) <= 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?
- 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, ...).
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...).
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));
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. calibration).
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.
Thanks!
> > > 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.
>
> ACK. 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) <= 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?
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 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.
> 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
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. calibration).
>
> 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 <data> AND <mask> ==
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...
>>ACK. 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) <= 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.
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 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.
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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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, 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.).
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. calibration).
> >
> >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 <data> AND <mask> ==
> 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?
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 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...
I can understand that, however, when the only difference is in the
actual _mounting_ of the hardware ... I'm not so sure.
> >>ACK. 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) <= 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.
>
> 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
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.
Very true.
>[...]
>>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.
Agreed.
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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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));
On Wed, 2005-02-09 20:18:17 +0100, Vojtech Pavlik <[email protected]>
wrote in message <[email protected]>:
> > 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 [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));
On Wed, 2005-02-09 19:54:04 +0000, Paulo Marques <[email protected]>
wrote in message <[email protected]>:
> >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.
...and for X11. Maybe we'd start talking about an API for this lib? At
least, my employer is interested I guess. (But this is OT wrt. the Linux
kernel, could you contact me at [email protected]?)
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));
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 level,
> since 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
Jan-Benedict Glaw wrote:
> On Wed, 2005-02-09 18:08:10 +0000, Paulo Marques <[email protected]>
> wrote in message <[email protected]>:
>
>[...]
>>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 <press
Alt>+<numeric X>+<numeric Y>+<numeric Z>+<release Alt> without even
bothering to release the numeric keys, to generate ASCII code XYZ :P
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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));
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 <[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.
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
On Wed, 2005-02-09 21:10:32 +0100, Vojtech Pavlik <[email protected]>
wrote in message <[email protected]>:
> On Wed, Feb 09, 2005 at 09:03:51PM +0100, Jan-Benedict Glaw wrote:
> > 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...
>
> I'll need some specific examples of protocols the keyboard use to judge
> how to tackle that.
I'll try to get some showkeys dumps for you tomorrow. This will be sent
to you privately since it may contain real card data...
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));
On Wed, 2005-02-09 22:53:35 +0100, Vojtech Pavlik <[email protected]>
wrote in message <[email protected]>:
> > 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.
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.
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));
Jan-Benedict Glaw wrote:
> On Wed, 2005-02-09 22:53:35 +0100, Vojtech Pavlik <[email protected]>
> wrote in message <[email protected]>:
>
>>>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) <= 20, so resolution would be
> 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)<=20, the TS controller must be
"trying" to do some calibration itself.
That's the brain-damaged part.
The TS controller should not be doing any calibration at all, and send
the widest range it can through the serial port to the PC.
On the PC we must have a library that is capable of scaling / rotating
those values so that it converts them into "screen absolute"
coordinates. I call these screen absolute because they shouldn't depend
on the actual resolution.
So there is no doubt that calibration must be done. We are past that. I
too work with touch screens in restaurants for more than 10 years now,
so I surely know what an agrssive environment is, and what damage a
touchscreen might be exposed to.
So, if the inputattach program initializes the TS controller to make it
send the widest range (1:1 calibration) it can deliver, we can do all
the calibration on the PC and not depend on the TS being able to do the
calibration itself.
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).
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Thu, 2005-02-10 13:06:46 +0000, Paulo Marques <[email protected]>
wrote in message <[email protected]>:
> 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) <= 20, so resolution would be
> > 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)<=20, the TS controller must be
> "trying" to do some calibration itself.
All touchscreens get calibrated once during their production AFAIK. This
should result at least in a "useable" resolution. ...but have a tight
look at today's touches: their [xy]{min,max} values don't cover all the
theoretical range of values that could be sent with the protocol in use.
Just taking an example, one screen here (it has never ever been
physically recalibrated except right after production) used values (for
X as well as for Y) in the range of about [350..3800]. The protocol does
allow a lot more...
> That's the brain-damaged part.
It's not :) The foil layers aren't all that equal after production.
They're (from the protocol point of view) generalized by calibrating
them once (during production). However, if the screen gets injured, this
must either be re-done, or the screen may need to be replaced. However,
replacing parts in the field is expensive and service staff tries to not
do that, but instead a recalibration is tried first. IFF the touchscreen
is then found to be *really* dead, it's replaced.
> The TS controller should not be doing any calibration at all, and send
> the widest range it can through the serial port to the PC.
But it needs to know the exact range of possible resistance/capacity to
be able to do that. This is where the trouble starts that I'm talking
about. Of course you can *assume* that capacity will be in a
(well-known) range (you know the range because you can just test a
production example), but this range is a bit different for each
touchscreen produced, let alone the fact that the foils may get
scratches or other injuries. In a bad case, you get a near-short-circuit
so that your (new) range of values is near-zero. Recalibrating the A/D
converter may revive this almost-dead screen.
> On the PC we must have a library that is capable of scaling / rotating
> those values so that it converts them into "screen absolute"
> coordinates. I call these screen absolute because they shouldn't depend
> on the actual resolution.
>
> So there is no doubt that calibration must be done. We are past that. I
> too work with touch screens in restaurants for more than 10 years now,
> so I surely know what an agrssive environment is, and what damage a
> touchscreen might be exposed to.
Right, but there are two kinds of calibration:
(1) Mapping the raw capacity/resistor values (that only the TS controller
is aware of) to something the HID API can output. (This, too, includes
that the kernel dictates the range of values that can be reached).
(2) Mapping the range of reachable HID coordinates to actual on-screen
pixels. (This accounts for a person't fat and/or un-even fingers...)
"Calibration" in X11 with all it's drivers is done at the (2) level. You
first have to figure out the range of generated values and then place
these as [xy]{min,max} values.
However, the hardware-internal mapping (1) isn't covered anywhere right
now. This usually isn't much of a problem during real use, but it *is* a
problem if the hardware ever gets damaged (or the controller's flash
breaks). Ever tried to use a serial sniffer on vendor's original MS
Windows drivers? They almost always update the controller's internal
mapping, too.
> So, if the inputattach program initializes the TS controller to make it
> send the widest range (1:1 calibration) it can deliver, we can do all
> the calibration on the PC and not depend on the TS being able to do the
> calibration itself.
This is nice, but even cannot be done with all TS controllers. The very
old ones actually just hand over the pure A/D values as a 10bit integer.
For sure, you won't ever see a touchscreen that covers the whole scale:)
> 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).
ACK. We'd do a lib for that and have a X11 driver to make use of it.
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));
Jan-Benedict Glaw wrote:
> On Thu, 2005-02-10 13:06:46 +0000, Paulo Marques <[email protected]>
> wrote in message <[email protected]>:
> [...]
>>To get raw values that are (xmax-xmin)<=20, the TS controller must be
>>"trying" to do some calibration itself.
>
>
> All touchscreens get calibrated once during their production AFAIK. This
> should result at least in a "useable" resolution. ...but have a tight
> look at today's touches: their [xy]{min,max} values don't cover all the
> theoretical range of values that could be sent with the protocol in use.
> Just taking an example, one screen here (it has never ever been
> physically recalibrated except right after production) used values (for
> X as well as for Y) in the range of about [350..3800]. The protocol does
> allow a lot more...
This happens because the touch area is in fact a little larger than the
screen (and there are probably some protection resistors in series with
the touch) and you have 12-bit A/D that should give values [0..4095].
You still have more than enough range to calibrate in software.
The protocol has nothing to do with this. It is the number of bits in
the A/D converter that matter. Usually you will have 2 bytes for each
coordinate but only N bits will actually contain data, with N being the
A/D resolution.
>>That's the brain-damaged part.
>
>
> It's not :) The foil layers aren't all that equal after production.
> They're (from the protocol point of view) generalized by calibrating
> them once (during production). However, if the screen gets injured, this
> must either be re-done, or the screen may need to be replaced. However,
> replacing parts in the field is expensive and service staff tries to not
> do that, but instead a recalibration is tried first. IFF the touchscreen
> is then found to be *really* dead, it's replaced.
So you're seriously saying that a perfectly good touchscreen, that
returned values in the range [350..3800] after being injured might give
values in a range (xmax-xmin)<=20 ??? That's a pretty nasty injury...
More to the point, usually when you send calibration data into the TS
controller, it doesn't change anything at the analog level, it only
makes the controller do some math on the A/D data before sending it to
the PC. That doesn't help us at all.
>>The TS controller should not be doing any calibration at all, and send
>>the widest range it can through the serial port to the PC.
>
>
> But it needs to know the exact range of possible resistance/capacity to
> be able to do that. This is where the trouble starts that I'm talking
> about. Of course you can *assume* that capacity will be in a
> (well-known) range (you know the range because you can just test a
> production example), but this range is a bit different for each
> touchscreen produced, let alone the fact that the foils may get
> scratches or other injuries. In a bad case, you get a near-short-circuit
> so that your (new) range of values is near-zero. Recalibrating the A/D
> converter may revive this almost-dead screen.
The way a resistive touchscreen works, the controller doesn't need to
know at all the value of the total resistance. A capacitive TS might
need some calibration, but nowhere near to the amount that makes a 12
bit A/D return a 4/5 bit range.
In more than 10 years of touch screen usage, I've never seen a case like
you describe, so it's pretty hard for me to believe that:
a) you can get a resistive touch screen to give values (xmin-xmax)<=20
just by injuring it, but in a way that it can be revived
b) you can revive it by just changing the calibration parameters on the
TS controller
I believe you can make a touch screen controller return values in a very
short range if you try to use its internal calibration and mess up the
values really badly. In this case, recalibrating will almost certainly
make it work again.
>[...]
> Right, but there are two kinds of calibration:
>
> (1) Mapping the raw capacity/resistor values (that only the TS controller
> is aware of) to something the HID API can output. (This, too, includes
> that the kernel dictates the range of values that can be reached).
I would really like to see a datasheet of a TS controller that actually
does this, before we start working on a solution for it.
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.
> [...]
> However, the hardware-internal mapping (1) isn't covered anywhere right
> now. This usually isn't much of a problem during real use, but it *is* a
> problem if the hardware ever gets damaged (or the controller's flash
> breaks).
Why would a flash break if you never write to it? I would expect the TS
layers to be damaged before any electronic part gets broken...
> Ever tried to use a serial sniffer on vendor's original MS
> Windows drivers? They almost always update the controller's internal
> mapping, too.
That is because they were done by the same brain-damaged people that
didn't yet realize that a PC can do the couple of multiplications /
divisions necessary in a few nanoseconds and still believe that the TS
controller is "alleviating" the burden of the PC by doing that _complex_
math itself :P
>[...]
>>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).
>
>
> ACK. We'd do a lib for that and have a X11 driver to make use of it.
Ok, lets start working on it then :)
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Thu, 2005-02-10 15:35:28 +0000, Paulo Marques <[email protected]>
wrote in message <[email protected]>:
> Jan-Benedict Glaw wrote:
> So you're seriously saying that a perfectly good touchscreen, that
> returned values in the range [350..3800] after being injured might give
> values in a range (xmax-xmin)<=20 ??? That's a pretty nasty injury...
Right. This is what I'm saying. And recalibration of the TS controller
can (in _most_ cases) fix that.
> a) you can get a resistive touch screen to give values (xmin-xmax)<=20
> just by injuring it, but in a way that it can be revived
With some digging, maybe I can even find such a beast somewhere around
here (working for a software company, I don't my hands on large
quantities of broken hardware...).
> b) you can revive it by just changing the calibration parameters on the
> TS controller
>
> I believe you can make a touch screen controller return values in a very
> short range if you try to use its internal calibration and mess up the
> values really badly. In this case, recalibrating will almost certainly
> make it work again.
:-) That's just messing up it's "proper" calibration and restoring
working parameters.
> >[...]
> >Right, but there are two kinds of calibration:
> >
> >(1) Mapping the raw capacity/resistor values (that only the TS controller
> > is aware of) to something the HID API can output. (This, too, includes
> > that the kernel dictates the range of values that can be reached).
>
> I would really like to see a datasheet of a TS controller that actually
> does this, before we start working on a solution for it.
One of {elo,mu}touch does this. Unfortunately, the commands aren't
documented in the publically available sheets you can download from
their site. Using a serial sniffer, you can easily dismantle the
protocol to face the fact: these controller are a lot more clever than
the sheets will tell you :-)
> Why would a flash break if you never write to it? I would expect the TS
> layers to be damaged before any electronic part gets broken...
That's simple: some plastic/rubber shoes on equal ground, you can easily
load yourself with some 10000V. Touch it once, maybe it survives the
smoke. And possibly, the controller will loose it's flash contents...
Decalibrating by electrostatic discharge is even something that our
customers are able to _mention_ at the phone ("My finger hurt, it felt
like something bite me, the muscles and nerves hurt in my arm, the
computer crashed and upon reboot, I couldn't press the correct
pictograms...")
> >Ever tried to use a serial sniffer on vendor's original MS
> >Windows drivers? They almost always update the controller's internal
> >mapping, too.
>
> That is because they were done by the same brain-damaged people that
> didn't yet realize that a PC can do the couple of multiplications /
> divisions necessary in a few nanoseconds and still believe that the TS
> controller is "alleviating" the burden of the PC by doing that _complex_
> math itself :P
Yeah, right you are.
> >[...]
> >>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).
> >
> >ACK. We'd do a lib for that and have a X11 driver to make use of it.
>
> Ok, lets start working on it then :)
Sure. (I'll write you off-list tomorrow.)
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));
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).
> >
> >ACK. 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