EVIOC mechanism for MT slots

Thu Jan 20 23:58:08 PST 2011

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 <chris at cnpbagwell.com> wrote:
> 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
>>
> --
> 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
>