EVIOC mechanism for MT slots

[Ping Cheng]

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