Enabling multitouch in input-evdev

[Peter Hutterer]

On Mon, Jan 18, 2010 at 01:02:54PM +0100, Benjamin Tissoires wrote:
> Peter Hutterer wrote:
> >First of all, thanks for your efforts here. I really appreciate that you
> >pushed it that far and I'm sorry about the delay in my comments.
> >
> >On Fri, Jan 08, 2010 at 12:55:21PM +0100, Benjamin Tissoires wrote:
> >>First, I try to dynamically create/detroy such subdevices. However,
> >>it infers very often freezes in the Xserver due to some mallocs. So
> >>the idea to solve this problem is to staticaly allocate the
> >>subdevices.
> >
> >Do you have any logs or other data on where these freezes occured? they'd be
> >useful for others as well since chances are someone is going to run into
> >this deadlock.
> >
> Sorry, when this freezes occurs I only had backtracks from the
> driver (a xmalloc) and not the other threads (I forgot to check
> them). I add this to my todo list.

Right, as Julien said you can't malloc in evdev. Any path that's hit during
ReadInput cannot malloc anything.

> >The evdev driver is first and foremost a generic mouse driver. Which means
> >that devices that provide x and y are the most important to work, regardless
> >of relative or absolute. The need for x/y is also implied by the core
> >protocol. However, there's no reason that you couldn't fake up x/y
> >and simply leave it as a mute axis. IMO the kernel should not report axes
> >that don't exist.
> >The axis mapping evdev is a convention not a rule, so you could just
> >reshuffle the axis checking to cater for the multitouch situation.
> >That goes for the rest of the driver too, if something seems wrong to cater
> >for a new situation then the driver can be rewritten to suit this.
> >
> As I had to rewrite the patch to keep all the events in one device,
> I will have to play with axes... and tackle this issue.

right, you could have an 0/1 axis for this type of things, that's about the
best approach. there's also the chance of using a button but that's more
likely to be misinterpreted.
the correct approach is that you only send those axes with a value, thus
explicitly specifying the on/off. This is possible with XI2 but the input
driver APIs aren't in place for that (no need so far).

> One last question I forgot to ask:
> Do we need to dynamically change the number of touch that can be detected ?
> I.e. do we need to have only 10 touches (as in Windows I think) or
> do we let the choice to the user (the toolkit) if the device can
> handle more ?

same again, you can change the number of axes in XI2, it's just that the
input driver APIs are missing that feature so far.
 
Cheers,
  Peter