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

[Peter Hutterer]

On Tue, Nov 09, 2010 at 12:10:26PM -0800, Ping Cheng wrote:
> 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. 

yes please! in the X driver, I shouldn't have to care if the tablet is usb,
serial or pigeon based. likewise I shouldn't really have to worry about I4,
I3, Bamboo, Cintiq or whatever, just about the capabilities that the kernel
driver reports.

Right now, that's not the case and the amount of model checks we have in the
X driver is amazing. I realize that we may never get down to zero
model-specific code paths, but we could at least aim to get there.

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

well, we can add to the spec. lucky us. ;)

reporting touch input through and axis that's labelled as rotation is the
fast-track to pain. it makes generic user-space code really hard.

Cheers,
  Peter

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