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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
