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

[Benjamin Tissoires]

Le 08/11/2010 04:51, Peter Hutterer a écrit :
> fwiw, I'm not sure "arbitrate" is the right word here, filtering seems
> easier to understand in this context. I guess "arbitrate" would apply more
> if we emit the events across multiple devices like in the bamboo case.
> that's mostly bikeshedding though, my points below apply regardless of what
> word we choose :)
>
> note that we also have two different approaches - single kernel device or
> multiple kernel devices and depending on the approach the device uses the
> options below have different advantages and disadvantages.
>
> the tablets I've dealt with so far exposed a single event device, so that's
> what I'm focusing on in this email.
>
> On Fri, Nov 05, 2010 at 11:47:28AM -0700, Ping Cheng wrote:
>> Recent changes and discussion about MT support at LKML, UDS, and
>> xorg-devel encouraged me to migrate Wacom MT devices to the slot-based
>> MT protocol (introduced in kernel 2.6.36). Since Wacom supports both
>> digitizer and touch devices, I need to decide how to report touch data
>> when the pen is in proximity.
>>
>> My goal is to understand how X server would like the MT data to be
>> reported from the kernel. I hope to keep kernel and X server driver MT
>> support in sync so we can avoid unnecessary confusion or extra work in
>> the userland.
>>
>> The existing solution for single touch events is to arbitrate touch
>> when pen is in prox. This is based on the assumption that we do not
>> want to have two cursors competing on the screen.
>>
>> With the introduction of MT, the touch data are most likely translated
>> into something other than pointer events. So, reporting both pen and
>> touch data makes sense now. However, I want to assure a smooth
>> tansition from single touch to MT for end users so they still get the
>> single touch behavior as they used to be. I gathered the following
>> approaches:
>>
>> 1.     Arbitrate all touch data in the kernel.
>>
>> This is the simplest solution for device driver developers. But I do
>> not feel it is end user and userland client friendly.
>
> I'm strongly opposed to this. kernel filtering of these devices is hard to
> circumvent and there _will_ be use-cases where we need more than one tool to
> work simultaneously. right now we're worrying about pen + touch, but what
> stops tablets from becoming large enough to be used by 2+ users with 2+
> pens simultaneously?
>
> from a purely event-stream focused viewpoint: why do we even care whether
> something is a pen or a touch? both are just tools and how these should be
> used is mostly up to the clients anyway.  IMO, the whole point of
> MT_TOOL_TYPE is that we don't have to assume use-cases for the tools but
> just forward the information to someone who knows how to deal with this.
>
>> 2.     Report first finger touch as ABS_X/Y events when pen is not in
>> prox.  Arbitrating single touch data when pen is in prox. Pen data is
>> reported as ABS_X/Y events. Both ABS_X/Y for pen or the first finger
>> and ABS_MT_* for MT data are reported.
>>
>> This approach reduces the overhead in dealing with two cursors in userland.
>>
>> 3.    Report first finger touch as ABS_X/Y events when pen is not in prox;
>>         Report pen data as ABS_X/Y events when there is no finger touch;
>>         Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
>> events when both pen and touch data are received. No ABS_X/Y are
>> reported when pen and tocuh or multi-touch data are received.
>>
>> I feel this one makes sense to userland since pen can be considered as
>> another touch.
>>
>> 4.    Report first finger touch as ABS_X/Y events when pen is not in prox;
>>         Report pen data as ABS_X/Y events when there is no finger touch;
>>         Report touch data as MT_TOOL_TOUCH and pen data as MT_TOOL_PEN
>> events when both pen and touch data are received. ABS_X/Y are also
>> reported for pen when both pen and tocuh data are received.
>
> I'd vote for this one. It provides all the data necessary for MT clients
> (and all the data the device can support) but has a reasonable single-touch
> strategy. Given that wacom tablets are still primarily pen-centric tablets,
> the emphasis on pen overriding touch makes sense to me.

Hi,

I'd also vote for this.

I don't think that the kernel should make any assumption on the final 
application. The data are available, so we have to pass them.

1. I read that people worry about sending "false" events (touch) while 
using the pen. But in my mind, this is a _design_ problem of the final 
application. I think the final application will have to filter these 
events: for instance, what happens if the user is too lazy to remove his 
pen (or just want to keep the hover on the application) out of the 
proximity range and want to move its digital sheet of paper in his (her) 
design application? The final application will have to choose whether 
using or not the touch features (depending on the pressure for instance...).

The solution 4. (*technical solution*) addresses the problem of the 
"false" events for the applications (*design problem*) that are not 
designed to used multitouch. They will just ignore the touch data.
So I think, it's a good start


2. I would also add that multitouch is not only available for trackpads: 
there are also direct devices in absolute coordinate mode. With those 
device, the touch data can be directed to an other Xclient that is used 
by an other user if the surface is large enough. Currently we only see 
relatively small surfaces (bamboo, ntrig devices), but in the future, we 
can easily imagine a whole table with both pen and touch.

And this solve Michal's problem as he will be able to use buttons in the 
application with the finger.

Cheers,
Benjamin

>
>> This one makes sense to userland too. It eases the backward
>> compatibility support for those clients that don't support MT at all.
>>
>> Which approach do you like? Or do you have other suggestions share?
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel