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));

Attachment: signature.asc
Description: Digital signature

Reply via email to