Adding support for a (multi-)touchscreen - where best to add it?

[Peter Hutterer]

On Mon, Mar 16, 2009 at 06:28:40AM -0500, David Hagood wrote:
> On Mon, 2009-03-16 at 11:05 +1000, Peter Hutterer wrote:
> > that's probably because they advertise a button/axis combination that evdev
> > does interpret correctly, or because they're posting the axis information
> > wrongly. I had my hands on an HP Touchsmart for a short while and it was
> > posting x/y through Z/Rx.
> Yes, that is also what I was seeing with the 3M. Either this means that
> evdev needs a good way to remap pointer axis based upon HAL data (so
> that you could set up the .fdi) OR evdev need enough smarts to say
>   IF device is touchscreen AND device does not report X/Y axis
>   THEN remap whatever axis device does report and log device is stupid.

no. this should be fixed in the kernel, not in evdev.

aside from that - yes, axis remapping is needed, not in evdev but in the
server so all devices can use it. axis remapping is a UI feature though and
not supposed to be used to fix broken devices.

> > sort-of. except that there's a huge difference between multi-touch,
> > multi-point and multi-touch-multi-point.
> ...
> > touch: not a single point, but a single area. touching with a thumb is
> > different than touching with a stylus. touch screens that only to single
> > point interaction are technically no different to a mouse.
> > 
> This is what I am interested at this moment: the screen I am working
> with returns a rectangle for the touch area.
> 
> > Oh, and there's also some fun in providing touch support in standard apps that
> > think that your fingers are a mouse.
> > 
> > Cheers,
> >   Peter
> > 
> > PS: google for multi-touch demonstration and try to find one that doesn't just
> > use one full-screen app. Not a lot of them around.
> > 
> Again, in my case this is not a big issue, as this is in support of a
> full-screen application ("embedded" system, though not as most people
> think of as "embedded" as the device in question is pretty large in size
> and in computing power).
> 
> Again, I'm just trying to map out the most direct route from what I have
> to what will work (without making too many stupid decisions along the
> way) - That's why I am beginning to thing that maybe tslib might be the
> better medium term approach, as I can do all the fiddly-bits (e.g.
> sending the special wakeup packet to the panel, parsing the funny packet
> back) from user space rather than kernel space, even though long term
> the better place might be in the kernel + evdev.
> 
> I've also added my work email so I can see these at work - unfortunately
> I really cannot use my work email for sending to the list as the
> Corporate Lawyers insist upon a half-page wart being added at the mail
> server.
 
for now, tslib or whatever custom approach is probably best. the kernel bits
will take a while to get sorted out (AFAIK), and the X parts probably even
longer.
 
Cheers,
  Peter