[RFC XI 2.1 - xf86-input-evdev 2/3] Add experimental XI 2.1 multitouch support

[Chase Douglas]

On 11/19/2010 01:29 AM, Peter Hutterer wrote:
> On Fri, Nov 12, 2010 at 05:35:12PM -0500, Chase Douglas wrote:
>> From: Chase Douglas <chase.douglas at ubuntu.com>
>>
>> This multitouch addition only supports slotted MT evdev protocol
>> devices. Support must be enabled at configure time using
>> --enable-multitouch. It is built on the masked valuator support in
>> XInput ABI 12, so do not attempt to build it for an earlier ABI.
>>
>> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
>> ---
>>  configure.ac |   11 ++++
>>  src/evdev.c  |  159 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
>>  src/evdev.h  |    5 ++
>>  3 files changed, 167 insertions(+), 8 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 07cd64e..cc9e721 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -47,6 +47,17 @@ XORG_DEFAULT_OPTIONS
>>  # Obtain compiler/linker options from server and required extensions
>>  PKG_CHECK_MODULES(XORG, xorg-server xproto inputproto)
>>  
>> +# Whether to include support for experimental XI 2.1 multitouch
>> +AC_ARG_ENABLE(multitouch,
>> +              AC_HELP_STRING([--enable-multitouch],
>> +                             [Enable experimental XI 2.1 multitouch support [[default: disabled]]]),
>> +              [MULTITOUCH=$enableval],
>> +              [MULTITOUCH=no])
>> +
>> +if test "x$MULTITOUCH" = xyes; then
>> +        AC_DEFINE(MULTITOUCH, 1, [Enable experimental multitouch code])
>> +fi
>> +
> 
> keep it on a branch and skip this bit.

Ok.

> I'll give a high-level review of these bits only because with the
> requirements for masked valuators the ifdef stuff goes away and the next
> patch will look quite different anyway.
> 
> the touch event processing skips the event queue completely. I don't think
> that's a good idea and we've had problems with this in the past. In the past
> this was because we'd post button events before motion events if they were
> within the same sync window. I think this here has the danger to suffer from
> the same issue, even though the current MT protocol makes this less of an
> issue.
> 
> so I'd say queue them up like other events, then send them when the EV_SYN
> comes around. this way the driver keeps the clean split between
> queueing/processing.

Ok, I can try that.

> on-the-side question that I just thought of: will having
> XIDirectTouch/XIDependentTouch on a device be equally limiting as having a
> single axis mode in XI 1.x?

Can you provide more detail? I don't see the parallel yet.

If you're thinking that each touch axis valuator could have it's own
direct/dependent mode, I don't really understand what that would mean.

Thanks,

-- Chase