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

[Peter Hutterer]

On Mon, Dec 13, 2010 at 12:28:30PM -0800, Chase Douglas wrote:
> On 12/09/2010 05:29 PM, Peter Hutterer wrote:
> > On Mon, Dec 06, 2010 at 09:41:48AM -0800, Chase Douglas wrote:
> >> On 12/05/2010 10:41 PM, Peter Hutterer wrote:
> >>> if the kernel can send it through one device, we can handle it, right?
> >>> if both are sent through the same axes (and need a serial or something to
> >>> differentiate like the wacom drivers) then yes, they need to be split up
> >>> into multiple devices.
> >>
> >> I think we're in agreement about what we can handle. We should be able
> >> to handle whatever the kernel sends us. But I feel that it's impossible
> >> to have a kernel device that sends touch information through the same
> >> properties for different surfaces. Thus, we don't need per-axis touch modes.
> > 
> > it's much easier for the kernel to add new information to the event
> > interface that it is for us to change the protocol. the initial MT protocol
> > didn't have pressure, for example, no tracking ID (IIRC), etc. all these
> > have been added since, while we were stuck with the same protocol version.
> > how hard would it be to add REL_MT_POSITION_X to the kernel and have devices
> > send events?
> 
> Certainly there are issues we find as we develop new protocols and then
> have new capabilities added to devices. There's a limit, though, to what
> we can prognosticate. I believe we've reached such a limit here.
> 
> As far as REL_MT_POSITION_X is concerned, I think the current X protocol
> would handle that just fine. Of course, I don't have any idea what
> REL_MT_POSITION_X means, but I think it would just be turned into
> positions on screen in the server before events are sent to clients.
> 
> > so unless you're _sure_ that in two or three years time we won't have
> > devices with multiple modes I'd say add a per-valuator flag. Worst case,
> > it's always 0 or 1 for all valuators for the forseeable future.
> 
> I understand the urge to make it per-valuator, and it wouldn't hurt, but
> it seems like over-engineering the issue. I can't even figure out how
> events are supposed to be handled with per-valuator modes.
> 
> For example, lets say there's a device with a touchscreen and two touch
> strips. Let's assume the kernel provides us with ABS_MT_POSITION_{X,Y}
> and maybe ABS_STRIP1_Y and ABS_STRIP2_Y. Each area also has a touch
> pressure axis. Here's what the touch class could look like with
> per-valuator modes:
> 
> 0: Touchscreen X, direct
> 1: Touchscreen Y, direct
> 2: Touchscreen Pressure, direct
> 3: Strip 1 Y, indirect
> 4: Strip 1 Pressure, indirect
> 5: Strip 2 Y, indirect
> 6: Strip 2 Pressure, indirect
> 
> X valuator axes are labelled. This is how the client knows what the axis
> represents. We would need to define new labels to distinguish axes 1, 3,
> and 5 from each other. Similarly for 2, 4, and 6. Imo, doing so would
> just be messy and difficult for client applications to use.

we already have this problem and it's not really the issue that this thread
is about.
check the evdev code, it struggles to handle devices that have both ABS_X
and REL_X on one device because we have no meaningful way to handle them
properly. (Mind you, this statement may be incorrect now as the server has
changed enough that we might be able to handle both axis in evdev now)

the more likely scenario would be a device with mixed mode for
non-overlapping axes.
0: Touchscreen X, indirect
1: Touchscreen Y, indirect
2: Touchscreen Pressure, direct

Cheers,
  Peter

> Further, I don't believe the kernel evdev interface would ever be
> extended in the same way.
> 
> Note that the above is based on touch strips which could be provided for
> through the normal pointer class valuators much more easily. However,
> the issues noted above may be extrapolated to multiple 2D input surfaces
> of the same device.
> 
> Instead, we could simply use separate input devices for each distinct
> physical input region. If you expand the above scenario to a device with
> two or more 2D touch areas, then I think the kernel would do this in the
> driver anyways.
> 
> To summarize, I just don't understand how per-valuator modes would give
> us any better functionality without being much messier than separate
> input devices. It feels like reinventing the master-slave pointer
> mechanism. I would be happy to reconsider if anyone could come up with a
> viable use case that would illustrate the benefits of per-valuator modes.