All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: LKML <linux-kernel@vger.kernel.org>,
	Linux-Input <linux-input@atrey.karlin.mff.cuni.cz>,
	Paulo Marques <pmarques@grupopie.com>
Subject: Re: [RFC/RFT] [patch] Elo serial touchscreen driver
Date: Wed, 9 Feb 2005 18:30:26 +0100	[thread overview]
Message-ID: <20050209173026.GA17797@ucw.cz> (raw)
In-Reply-To: <20050209171438.GI10594@lug-owl.de>

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

  reply	other threads:[~2005-02-09 17:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-08 16:42 [RFC/RFT] [patch] Elo serial touchscreen driver Vojtech Pavlik
2005-02-08 16:54 ` Dmitry Torokhov
2005-02-09 13:23 ` Paulo Marques
2005-02-09 17:00   ` Vojtech Pavlik
2005-02-09 17:14     ` Jan-Benedict Glaw
2005-02-09 17:30       ` Vojtech Pavlik [this message]
2005-02-09 18:08         ` Paulo Marques
2005-02-09 19:18           ` Vojtech Pavlik
2005-02-09 19:54             ` Paulo Marques
2005-02-09 20:06               ` Jan-Benedict Glaw
2005-02-09 20:03             ` Jan-Benedict Glaw
2005-02-09 20:10               ` Vojtech Pavlik
2005-02-09 21:53                 ` Jan-Benedict Glaw
2005-02-09 19:58           ` Jan-Benedict Glaw
2005-02-09 20:51             ` Paulo Marques
2005-02-09 21:39               ` Jan-Benedict Glaw
2005-02-09 21:53                 ` Vojtech Pavlik
2005-02-10 10:46                   ` Jan-Benedict Glaw
2005-02-10 13:06                     ` Paulo Marques
2005-02-10 13:43                       ` Jan-Benedict Glaw
2005-02-10 15:35                         ` Paulo Marques
2005-02-10 15:55                           ` Jan-Benedict Glaw
2005-02-10 16:16                           ` Vojtech Pavlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050209173026.GA17797@ucw.cz \
    --to=vojtech@suse.cz \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.