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

[Ping Cheng]

On Thu, Dec 2, 2010 at 7:37 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Thu, Dec 02, 2010 at 10:34:44AM -0500, Chase Douglas wrote:
>> On 12/02/2010 10:28 AM, Daniel Stone wrote:
>> > On Thu, Dec 02, 2010 at 10:06:01AM -0500, Chase Douglas wrote:
>> >> Instead, we could create separate input devices for the strip and the
>> >> touchscreen. The strip would be a dependent device, and would usually be
>> >> attached to the same MD as the touch screen. However, it could also be
>> >> attached to a different MD, allowing for more interesting mixing and
>> >> matching of input devices.
>> >
>> > We could make the mode in the touch class a bitmask of direct and
>> > dependent, and let the driver tell us at touch creation time whether the
>> > touch should be direct or dependent?
>>
>> That doesn't resolve the issue of sending two separate touch events from
>> two separate "devices" through one XI device. What if the intuos had
>> another touch strip? The touch event would have to distinguish between
>> the two strips somehow. I think the only way to do that would be through
>> a valuator, which would just be fitting a square peg into a round hole.
>
> Indeed.  If we need to distinguish between the different touch strips,
> then the only option is having multiple devices, and at that stage I
> think we should really revisit the idea of a deeper device hierachy
> (e.g. MD #1 -> Wacom tablet #1 -> {Pen, Eraser, touch strip #1, touch
> strip #2}).

I think we don't need to consider each touch strip as an independent
device. They can be grouped together as one device, called pad in
xf86-input-wacom now. The two strip data are then reported through two
axes of the pad. The problem is that pad does not sent motion events
since it is not a true pointer device. The events that invoked by the
strips are posted to wherever the current cursor is. In order to use
the XInput 1.0 design, we had to set pad to relative mode so it won't
move the cursor to (0.0). But, clients would like to have those strip
data in absolute value.

As Chase pointed out above, potentially, there is another approach for
us: attaching the strips as an extra feature to the tool that is on
the tablet. The tool can be a stylus/eraser/mouse or a touch depending
on which tool the strip data are reported with. This idea was
suggested by Dmitry at linux-input mailing list recently. However,
even with this approach, we still need to deal with the strips as an
independent device when no tool is on the tablet for strips to attach
to. The need of per-axis based mode mask stays. (x,y) will always be
in the same mode, I guess.

Ping