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.
> I work for a company that develops software for restaurants, and we have
> a Linux port of our main application running in actual restaurants with
> a custom made Linux distribution for about 2 years now.
>
> We had to support a number of touchscreens, and we do it in the
> application itself, reading the serial port and processing the data.
>
> If this could go into the kernel, then our application needed only to
> read the input device, and handle events, no matter what touch screen
> was there. That would be a great improvement :)
And I'm glad there is interest. :)
> I have one that uses the 10 byte protocol (I've never seen one ELOtouch
> that used one of the other protocols). I can give you some feedback as
> soon as I have some time to test it.
>
> >[...]
> >+ case 9:
> >+ if (elo->csum) {
> >+ input_regs(dev, regs);
> >+ input_report_abs(dev, ABS_X, (elo->data[4] <<
> >8) | elo->data[3]);
> >+ input_report_abs(dev, ABS_Y, (elo->data[6] <<
> >8) | elo->data[5]);
> >+ input_report_abs(dev, ABS_PRESSURE,
> >(elo->data[8] << 8) | elo->data[7]);
> >+ input_report_key(dev, BTN_TOUCH, elo->data[8]
> >|| elo->data[7]);
>
> This one is weird. In my code I have this:
>
> > button = ((buf[2] & 0x03) != 0);
My documentation doesn't seem to say anything about the Status (buf[2])
byte. If a touch bit is reported there, then great, I'll change the
driver to use that.
Right now the driver uses the Z value to tell if the screen is touched
or not.
> So maybe, ELO touchscreens that don't have pressure sense output, only
> send "touch down / up" information on the 2 LSB's of the third byte(?)
That's very likely.
> Anyway, inputattach should have a command line option to set the
> baudrate manually, as some of these touchscreens have configurable
> baudrates, and some POS manufacturers set them to non-default values.
That's rather easy to do.
> 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.
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.
--
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/
