Hi Dmitry,
Rafi's request is a good use case for the "input: mt: Add EVIOC
mechanism for MT slots" patchset that Henrik submitted last May. From
the MT X driver experience we had in the last few months, retrieving
all active contacts, especially in the case when different tool types
are supported on the same logical port, is necessary to initialize the
tools properly.
Can you consider to merge the patchset into 2.6.38?
Thank you.
Ping
-------- Original Message --------
Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots
Date: Thu, 27 May 2010 16:12:20 -0700
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Ping Cheng <redacted>
CC: Henrik Rydberg <redacted>, Andrew Morton
[off-list ref], linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Mika Kuoppala [off-list ref],
Peter Hutterer [off-list ref], Benjamin Tissoires
[off-list ref], Stephane Chatty [off-list ref], Rafi Rubin
[off-list ref], Michael Poole [off-list ref]
On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote:
On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov
[off-list ref] 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
>>
>> [off-list ref] 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
On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin [off-list ref] wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've come across a little problem with filtered MT events. It seems there
isn't a mechanism to request the full state. If a program opens a device
there's no way it can see static objects.
Consider for example a board game. If the user puts the pieces on a MT surface
before starting the application, those pieces will not register and the state of
the game will be incorrect.
If there's opposition to this request, I suggest settling the dispute with a
game of MT battleship :-)
Rafi
--
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
On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng [off-list ref] wrote:
Hi Dmitry,
Rafi's request is a good use case for the "input: mt: Add EVIOC
mechanism for MT slots" patchset that Henrik submitted last May. From
the MT X driver experience we had in the last few months, retrieving
all active contacts, especially in the case when different tool types
are supported on the same logical port, is necessary to initialize the
tools properly.
Can you consider to merge the patchset into 2.6.38?
Thank you.
Ping
Agree. Although X/Y will change often, the tracking ID is stable. So
during start up of applications it would be really useful to query
pre-existing ABS_MT_TRACKING_ID so that user doesn't have to lift
object/hand/whatever before application starts working.
Chris
-------- Original Message --------
Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots
Date: Thu, 27 May 2010 16:12:20 -0700
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Ping Cheng <redacted>
CC: Henrik Rydberg <redacted>, Andrew Morton
[off-list ref], linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Mika Kuoppala [off-list ref],
Peter Hutterer [off-list ref], Benjamin Tissoires
[off-list ref], Stephane Chatty [off-list ref], Rafi Rubin
[off-list ref], Michael Poole [off-list ref]
On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote:
On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov
[off-list ref] 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
>>
>> [off-list ref] 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
On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin [off-list ref] wrote:
quoted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've come across a little problem with filtered MT events. It seems there
isn't a mechanism to request the full state. If a program opens a device
there's no way it can see static objects.
Consider for example a board game. If the user puts the pieces on a MT surface
before starting the application, those pieces will not register and the state of
the game will be incorrect.
If there's opposition to this request, I suggest settling the dispute with a
game of MT battleship :-)
Rafi
--
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
--
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
Hi,
if the TrackingID is stable during the touch, the MT_SLOT is stable
*between* the touches:
if you put one finger on the surface, you get the slot 0. Then you
release. Then you touch one finger again, and protocol B does not send
the slot value.
This is really problematic when launching applications that rely on
evdev to work:
you click with the mouse emulation on your icon to launch the program
(one finger), and you start using your application with one finger
only (opening of a file for instance) -> you are in an unstable case
as the app does not know the slot state until you put another finger
on the screen.
So I'm in favor of applying this patch Henrik submitted last May.
Cheers,
Benjamin
On Fri, Jan 21, 2011 at 04:57, Chris Bagwell [off-list ref] wrote:
On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng [off-list ref] wrote:
quoted
Hi Dmitry,
Rafi's request is a good use case for the "input: mt: Add EVIOC
mechanism for MT slots" patchset that Henrik submitted last May. From
the MT X driver experience we had in the last few months, retrieving
all active contacts, especially in the case when different tool types
are supported on the same logical port, is necessary to initialize the
tools properly.
Can you consider to merge the patchset into 2.6.38?
Thank you.
Ping
Agree. Although X/Y will change often, the tracking ID is stable. So
during start up of applications it would be really useful to query
pre-existing ABS_MT_TRACKING_ID so that user doesn't have to lift
object/hand/whatever before application starts working.
Chris
quoted
-------- Original Message --------
Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots
Date: Thu, 27 May 2010 16:12:20 -0700
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Ping Cheng <redacted>
CC: Henrik Rydberg <redacted>, Andrew Morton
[off-list ref], linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Mika Kuoppala [off-list ref],
Peter Hutterer [off-list ref], Benjamin Tissoires
[off-list ref], Stephane Chatty [off-list ref], Rafi Rubin
[off-list ref], Michael Poole [off-list ref]
On Thursday, May 27, 2010 03:59:37 pm Ping Cheng wrote:
On Thu, May 27, 2010 at 12:03 AM, Dmitry Torokhov
[off-list ref] 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
>>
>> [off-list ref] 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
On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin [off-list ref] wrote:
quoted
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've come across a little problem with filtered MT events. It seems there
isn't a mechanism to request the full state. If a program opens a device
there's no way it can see static objects.
Consider for example a board game. If the user puts the pieces on a MT surface
before starting the application, those pieces will not register and the state of
the game will be incorrect.
If there's opposition to this request, I suggest settling the dispute with a
game of MT battleship :-)
Rafi
--
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
--
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
--
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
On Fri, Jan 21, 2011 at 10:15:19AM +0100, Henrik Rydberg wrote:
quoted
This is really problematic when launching applications that rely on
evdev to work:
you click with the mouse emulation on your icon to launch the program
(one finger), and you start using your application with one finger
only (opening of a file for instance) -> you are in an unstable case
as the app does not know the slot state until you put another finger
on the screen.
So I'm in favor of applying this patch Henrik submitted last May.
Great, so there seems to be sufficient interest to warrant revisiting
this. If you can find the patches, I will queue them in my tree. ;-)
And if Dmitry concurs, perhaps we can even aim at 2.6.38.
The reason I objected in the first place is that the patch was a "nice
to have for completeness". Now that there are actual users needing this
data I have no issues with adding ioctl to retrieve this data.
Thanks.
--
Dmitry