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

David Hagood david.hagood at gmail.com
Mon Mar 16 04:28:40 PDT 2009


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.

> 
> 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.




More information about the xorg mailing list