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

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

[Henrik Rydberg]

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.

Henrik Rydberg (2):
  input: mt: Add method to extract the MT slot state
  input: mt: Add EVIOC mechanism to extract the MT slot state

 drivers/input/evdev.c |    9 ++++++++-
 drivers/input/input.c |   31 +++++++++++++++++++++++++++++++
 include/linux/input.h |    2 ++
 3 files changed, 41 insertions(+), 1 deletions(-)

[PATCH 1/2] input: mt: Add method to extract the MT slot state

[Henrik Rydberg]

This patch adds the function input_mt_get_abs_value(), which may be
used to extract the current state of the MT slots.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
 drivers/input/input.c |   31 +++++++++++++++++++++++++++++++
 include/linux/input.h |    2 ++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 9b6d474..24d1105 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -659,6 +659,37 @@ static int input_default_setkeycode(struct input_dev *dev,
 }
 
 /**
+ * input_mt_get_abs_value - retrieve MT state variables from a device slot
+ * @dev: input device which state is being queried
+ * @code: ABS code to retrieve
+ * @slot: slot to retrieve from
+ *
+ * Return the ABS state of the given MT slot. If code is not an MT
+ * event, the corresponding ABS event is returned.
+ *
+ * This function may be called by anyone interested in extracting the
+ * current MT state. Used by evdev handlers.
+ */
+int input_mt_get_abs_value(struct input_dev *dev, unsigned int code, int slot)
+{
+	unsigned int mtmap = input_mt_abs_map[code];
+	unsigned long flags;
+	int retval;
+
+	spin_lock_irqsave(&dev->event_lock, flags);
+	if (!mtmap)
+		retval = dev->abs[code];
+	else if (slot >= 0 && slot < dev->mtsize)
+		retval = dev->mt[slot].abs[mtmap - 1];
+	else
+		retval = 0;
+	spin_unlock_irqrestore(&dev->event_lock, flags);
+
+	return retval;
+}
+EXPORT_SYMBOL(input_mt_get_abs_value);
+
+/**
  * input_get_keycode - retrieve keycode currently mapped to a given scancode
  * @dev: input device which keymap is being queried
  * @scancode: scancode (or its equivalent for device in question) for which
diff --git a/include/linux/input.h b/include/linux/input.h
index bea6958..03727d6 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -1436,6 +1436,8 @@ static inline void input_mt_slot(struct input_dev *dev, int slot)
 	input_event(dev, EV_ABS, ABS_MT_SLOT, slot);
 }
 
+int input_mt_get_abs_value(struct input_dev *dev, unsigned int code, int slot);
+
 void input_set_capability(struct input_dev *dev, unsigned int type, unsigned int code);
 
 static inline void input_set_abs_params(struct input_dev *dev, int axis, int min, int max, int fuzz, int flat)
-- 
1.6.3.3

[PATCH 2/2] input: evdev: Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

This patch adds the ability to extract the MT slot state sequentially
via EVIOCGABS. The slot parameter is first selected by calling
EVIOCSABS with ABS_MT_SLOT as argument, followed by a set of EVIOCGABS
calls. The slot selection is local to the evdev client handler, and
does not affect the actual input state.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
 drivers/input/evdev.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2ee6c7a..8b68b88 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -43,6 +43,7 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	int slot; /* used to extract MT events via EVIOC */
 };
 
 static struct evdev *evdev_table[EVDEV_MINORS];
@@ -624,7 +625,8 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 
 				t = _IOC_NR(cmd) & ABS_MAX;
 
-				abs.value = dev->abs[t];
+				abs.value = input_mt_get_abs_value(dev, t,
+					client->slot);
 				abs.minimum = dev->absmin[t];
 				abs.maximum = dev->absmax[t];
 				abs.fuzz = dev->absfuzz[t];
@@ -665,6 +667,11 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 								  sizeof(struct input_absinfo))))
 					return -EFAULT;
 
+				if (t == ABS_MT_SLOT) {
+					client->slot = abs.value;
+					return 0;
+				}
+
 				/*
 				 * Take event lock to ensure that we are not
 				 * changing device parameters in the middle
-- 
1.6.3.3

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

[Dmitry Torokhov]

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.

-- 
Dmitry

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

[Henrik Rydberg]

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.

Cheers,
Henrik

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

[Dmitry Torokhov]

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.

Thanks.

-- 
Dmitry

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

[Ping Cheng]

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

Hope I didn't miss too much this round :).

Ping

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

[Dmitry Torokhov]

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.

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

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

[Benjamin Tissoires]

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.

You can count me with as a user of this new protocol and whatever related.

Cheers,
Benjamin

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

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

[Dmitry Torokhov]

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.

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

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

[Benjamin Tissoires]

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

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

[Henrik Rydberg]

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

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

[Ping Cheng]

On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> 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.

tbh, I can not say that I will need it in my X driver for sure. But I
vote for it to be merged.

Thank you for placing me in such an important position :).

Ping

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

[Dmitry Torokhov]

On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote:
> On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov
> 
> <dmitry.torokhov@gmail.com> wrote:
> > 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.
> 
> tbh, I can not say that I will need it in my X driver for sure. But I
> vote for it to be merged.

Well, at this point I am in "no users - no functionality" mode, so I will
only count votes of users :P

-- 
Dmitry