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

[Chris Bagwell]

On Tue, Nov 9, 2010 at 10:46 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Mon, Nov 08, 2010 at 10:14:56PM -0600, Chris Bagwell wrote:
>>
>> I've copied #2 below and added my own text in "[]" to be sure and
>> clarify text in context of case #2.
>>
>> 2.     Report first finger touch as ABS_X/Y events [on touch input
>> device] when pen is not in
>> prox.  Arbitrating single touch data [on touch input device] when pen
>> is in prox. Pen data is
>> reported as ABS_X/Y events [on pen input device]. Both ABS_X/Y for pen
>> or the first finger
>> and ABS_MT_* for MT data are reported [each MT send].  [MT are even
>> sent on touch device even though only 1 in proximity tool possible so
>> that client can combine both inputs' events and see same behaviour as
>> if it was a single input device.]
>
> Assuming a split device - why do any filtering at all?
> Report ABS_X/Y for pen on the pen device, touch as MT events on the touch
> device _and_ first finger touch as ABS_X/Y on the touch device. If userspace
> can somehow couple the two devices then it's easy enough to filter touch
> events when necessary.

Who is audience of these ABS_X/Y events?  We are not sending them for
MT-aware application benefit.  Matter of fact, it slightly complicates
MT-aware apps because they have to filter them in addition to
filtering MT events.

The real audience of ABS_X/Y is either older apps or "simple" apps
(people that chose to keep it simple and not support MT events).  This
class of apps can't really be expected to bind two devices logically
and mask.  So without filtering ABS_X/Y on kernel side, we've
basically made Bamboo drivers unusable with a range of apps; which
probably means xf86-input-{evdev|synaptics} (I can't justify adding
binding logic to those two).

I think we also have some high level agreements that we should combine
input devices in kernel long term with minor technical decisions to be
made.  So that makes any logical binding code in xf86-input-*
transitional only.

So by masking in kernel for these special pen+touch 2 input case, its
simple, keeps Bamboo/Ntrig usable with existing
xf86-input-{evdev|synaptics|wacom} and keeps user land from writing
that transitional logic.

>
> Don't report pen as the only MT set on the pen device, that's just
> confusing.

Yeah, agree.  Its mainly only if it solves some large applications
binding issues but thats theoretically right now.  No real need to do
it.

>
> Does this answer your question?

Yes.  Thanks.

Chris