EVIOC mechanism for MT slots

[Chris Bagwell]

On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng <pinglinux at gmail.com> 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 at gmail.com>
> To:     Ping Cheng <pinglinux at gmail.com>
> CC:     Henrik Rydberg <rydberg at euromail.se>, Andrew Morton
> <akpm at linux-foundation.org>, linux-input at vger.kernel.org,
> linux-kernel at vger.kernel.org, Mika Kuoppala <mika.kuoppala at nokia.com>,
> Peter Hutterer <peter.hutterer at who-t.net>, Benjamin Tissoires
> <tissoire at cena.fr>, Stephane Chatty <chatty at enac.fr>, Rafi Rubin
> <rafi at seas.upenn.edu>, Michael Poole <mdpoole at troilus.org>
>
>
> 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 at 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 at 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
>
> On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin <rafi at seas.upenn.edu> 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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>