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

From: Vojtech Pavlik
Date: Wed Feb 09 2005 - 12:32:08 EST


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/