Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots

[Henrik Rydberg <rydberg@euromail.se>]

Benjamin Tissoires wrote:
> 
> 
> Le 27/05/2010 09:24, Dmitry Torokhov a écrit :
>> On Thu, May 27, 2010 at 09:08:10AM +0200, Benjamin Tissoires wrote:
>>> Le 27/05/2010 09:03, Dmitry Torokhov a écrit :
>>>> On Wed, May 26, 2010 at 08:59:35AM -0700, Ping Cheng wrote:
>>>>> On Tue, May 25, 2010 at 1:23 PM, Dmitry Torokhov
>>>>> <dmitry.torokhov@gmail.com>   wrote:
>>>>>> On Tue, May 25, 2010 at 09:52:29PM +0200, Henrik Rydberg wrote:
>>>>>>> Dmitry Torokhov wrote:
>>>>>>>> Hi Henrik,
>>>>>>>>
>>>>>>>> On Tue, May 25, 2010 at 01:52:57PM +0200, Henrik Rydberg wrote:
>>>>>>>>> These patches are in response to the discussion about input state
>>>>>>>>> retrieval.
>>>>>>>>>
>>>>>>>>> The current EVIOCGABS method does not work with MT slots.  These
>>>>>>>>> patches provides a mechanism where a slot is first selected via
>>>>>>>>> a call
>>>>>>>>> to EVIOCSABS, after which the corresponding MT events can be
>>>>>>>>> extracted
>>>>>>>>> with calls to EVIOCGABS.
>>>>>>>>>
>>>>>>>>> The symmetric operation, to set the MT state via EVIOCSABS,
>>>>>>>>> seems to
>>>>>>>>> violate input data integrity, and is therefore not implemented.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This looks sane, however the question remains - is there any
>>>>>>>> users for
>>>>>>>> this data? Like I mentioned, I can see the need to fetch state of
>>>>>>>> switches and ranges of absolute axis, and even non-multitouch
>>>>>>>> ABS values
>>>>>>>> (due to the fact that some input devices, like sliders, may stay
>>>>>>>> in a
>>>>>>>> certain position for long periods of time), but I expect
>>>>>>>> multitouch data
>>>>>>>> to be "refreshed" very quickly.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> There were some voices addressing this issue, and the patches are
>>>>>>> here,
>>>>>>> available for whomever to pick up. Drop them if you wish, I will
>>>>>>> not send them anew.
>>>>>>>
>>>>>>
>>>>>> I'll save them in my queue but will hold off applying until I hear
>>>>>> userspace folks requesting such functionality.
>>>>>
>>>>> Hi Dmitry,
>>>>>
>>>>> You do have a valid point - the (x,y) from a touch object would most
>>>>> likely change all the time. Even if the object itself is in a steady
>>>>> state on the digitizer, i.e., without any intentional movement, the
>>>>> electronic noise would most likely lead to some (x,y) changes. So, the
>>>>> chance that we need to retrieve (x,y) is rare.
>>>>>
>>>>> However, it is possibe that when X driver starts, an object was
>>>>> already on the digitizer. And the digitizer is of such a high quality
>>>>> :), it filtered all the noises so we can not locate the touch without
>>>>> a EVIOCGABS call.
>>>>>
>>>>> Plus, from a pure coding/development point of view, it is not a bad
>>>>> practice to provide the equivalent features for _MT_ support as we did
>>>>> for the existing input devices. At least, it doesn't hurt to make the
>>>>> support consistent across devices/tools (considering touch as a new
>>>>> input device/tool).
>>>>
>>>> Ping,
>>>>
>>>> I did not say that there was a problem with the patch, I agree with it.
>>>> However if no one using this - why should we bother? Will _you_ utilize
>>>> this functionality in Wacom X driver? If so let me know and I will
>>>> merge
>>>> it.
>>>>
>>>
>>> Hi Dmitry,
>>>
>>> I'm the guy who submitted some patchs to enable multitouch in the
>>> xf86-input-evdev driver. And I think that I will use the MT_SLOTS as
>>> soon as they are available. It is much easier for the upper part to
>>> have this protocol instead of the protocol type A.
>>>
>>
>> This is not the question about slotted protocol (which is everyone
>> agrees is needed), the question is whether anyone will use EIVICGABS to
>> retrieve the initial MT values in case someone started touching the
>> device before X opened the corresponding /dev/input/eventX.
>>
> 
> Sorry for the misunderstanding.
> 
> I can see at least 2 scenarios where such feature is interesting.
> 
> Scenario n°1:
> Imagine a mt-enabled surface, like the Microsoft Surface or other big
> devices. On these tables, we can put static objects that can be
> recognized by a tag or just by their weight, size, etc. These objects
> can be put before the X server starts and may be of interest. But since
> these objects are "statics" the kernel driver does not send new values
> and the X server does not see them, until they are moved by a human.
> 
> Here, I did not understood if the patch allows us to retrieve all slots
> that are currently present on the surface or if we can have only the
> last one.
> 
> Scenario n°2:
> The Apple Magicmouse. This device is a mouse with a mt-surface on top of
> it. If the filter is good enough, the device won't send the positions of
> the fingers that are on the surface as we have quite a static position
> while handling a mouse. In the case a user starts X and has a hand on
> the mouse, the X server won't see them until they are actually moved.
> This may not be a problem but if we need to know the mt-state while
> sending the clicks, the driver can misunderstand the user aim.
> But from what I understood, if the user has only one contact on the
> surface, the slot will not be send and the X driver will be a little bit
> lost concerning the slot in use.
> 
> So, I don't know if those patches will fit my needs, but for me, it is
> clear that the X server will need to retrieve the state of the
> mt-surface when the device is initialized.
> 
> I hope I'm not too far from the topic....
> 
> Cheers,
> Benjamin

Thank you Benjamin, you got it all right. I thought something similar to what
you describe when writing the patches. I agree with Dmitry that in general, an
MT contact state is dynamic enough not to need much state initialization, but I
also agree with you that there are cases where it is indeed needed.

Henrik

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html