lkml.org 
[lkml]   [2005]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/RFT] [patch] Elo serial touchscreen driver
On Wed, 2005-02-09 18:00:15 +0100, Vojtech Pavlik <vojtech@suse.cz>
wrote in message <20050209170015.GC16670@ucw.cz>:
> 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 jbglaw@lug-owl.de . +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));
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.231 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site