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

[Peter Hutterer]

On Fri, Dec 03, 2010 at 05:41:59PM -0800, Ping Cheng wrote:
> 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). 

That's an X server bug that IIRC has been fixed with 1.9.

Cheers,
  Peter

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