[RFC] Multi-Touch (MT) support - arbitration or not

[Ping Cheng]

On Tue, Nov 9, 2010 at 8:28 AM, Chris Bagwell <chris at cnpbagwell.com> wrote:
> On Tue, Nov 9, 2010 at 12:59 AM, Dmitry Torokhov
> <dmitry.torokhov at gmail.com> wrote:
>> On Tue, Nov 09, 2010 at 01:31:49PM +1000, Peter Hutterer wrote:
>>>
>>> That said, it also goes counter the whole multi-touch approach - allowing
>>> more than one device on a single physical device.
>>>
>>
>> So maybe we should teach wacom to handle all devices as a single input device even
>> in cases when they use several USB interfaces? We should be able to
>> detect related interfaces by examining intf->intf_assoc (I hope) and
>> using usb_driver_claim_interface() to claim them.
>
> Thanks for tips.  I may try it just to prove its possible.
>
> Here is extra info on resolution/dimension issue to also solve when
> combining.  Taken from current logic on touch input of Wacom Bamboo:
>
> input_mt_create_slots(input_dev, 2);
> input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, features->x_max,
> features->x_fuzz, 0);
>
> Combining 2 inputs means MT slots increases from 2 to 3 (2 touches and
> 1 stylus).
>
> Today, Pen has x_max=17420, x_fuzz=4 and resolution of 2540.  Also
> today, Touch has x_max=15360, x_fuzz=128 and resolution=dunno (we are
> scaling up touch x_max in driver and I haven't calculated its affects
> on resolution).
>
> I believe that a normalized value of x_max would show that there is a
> greater area of tablet can be used for touch then pen.

Normalization can be a way to address this issue. But, I am not sure
if we want normalization in the kernel. You are onto the right point
though. How are we going to pass the different resolution and x/y_max
with the same SLOT array? This is an issue we can not avoid for serial
MT devices since all data are from the same interface (your case #1).

The USB case (your case #2) can work around it since pen and touch are
on different logical port. But, I think we want to have an unified
approach for both serial and USB to avoid userland inconsistency. What
I did in the current code is to report touch x/y_max through ABS_RX/Y
so we don't step on ABS_X/Y for serial devices.

I know there are people don't like this idea either. So, any more suggestions?

Specifying individual resolution and x/y_max for each MT slot is
another way to address this issue. But that requires MT implementation
and (maybe) spec change.

Thank you for thinking out loud. I am sure you understood why I
haven't picked up that Bamboo for so long ;).

Ping

> To handle this difference, we can scale reported values in driver such
> that x_max=x_max for all slots.  I'm not clear on fuzz logic so don't
> know what 4 vs 128 does.
>
> Or we can maybe update MT interface so you can have per slot values
> for clients to query (or MT logic automatically scales for driver as
> another option).  Then slots 0-1 are reserved for touch and slot 3 is
> reserved for pen.
>
> Chris
>