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

[Chase Douglas]

On 12/13/2010 04:34 PM, Peter Hutterer wrote:
> 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

I'm not sure this was an apt example, it seems to be geared more towards
abs/rel instead of direct/indirect.

However, I've chatted with Peter on IRC about this. He's not convinced
that there won't be a use case that will need per-valuator modes. I
don't like having them, but they don't pose any technical issues by
their existence. All valuators will be either indirect or direct until
we find a future device that could use mixed modes.

Given that, I'm fine with adding them in. Peter, I may hunt you down for
a paragraph in the spec for per-valuator modes. I'm not sure I can
clearly articulate their value :).

-- Chase