From: Chris Bagwell <chris@cnpbagwell.com>
To: Ping Cheng <pinglinux@gmail.com>
Cc: Rafi Rubin <rafi@seas.upenn.edu>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Henrik Rydberg <rydberg@euromail.se>,
linux-input <linux-input@vger.kernel.org>,
Stephane Chatty <chatty@lii-enac.fr>,
Jiri Kosina <jkosina@suse.cz>,
Benjamin Tissoires <tissoire@cena.fr>,
Peter Hutterer <peter.hutterer@who-t.net>,
"X.Org Devel List" <xorg-devel@lists.freedesktop.org>
Subject: Re: EVIOC mechanism for MT slots
Date: Thu, 20 Jan 2011 21:57:47 -0600 [thread overview]
Message-ID: <AANLkTikksBMW0vcmJOGg8=VPWS3FB6HQQL46R7VotyON@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=mwmpV-db5evGsWe3eyNJER5DOH3V326Jf74us@mail.gmail.com>
On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng <pinglinux@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@gmail.com>
> To: Ping Cheng <pinglinux@gmail.com>
> CC: Henrik Rydberg <rydberg@euromail.se>, Andrew Morton
> <akpm@linux-foundation.org>, linux-input@vger.kernel.org,
> linux-kernel@vger.kernel.org, Mika Kuoppala <mika.kuoppala@nokia.com>,
> Peter Hutterer <peter.hutterer@who-t.net>, Benjamin Tissoires
> <tissoire@cena.fr>, Stephane Chatty <chatty@enac.fr>, Rafi Rubin
> <rafi@seas.upenn.edu>, Michael Poole <mdpoole@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@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
>
> On Thu, Jan 20, 2011 at 1:10 PM, Rafi Rubin <rafi@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@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
next prev parent reply other threads:[~2011-01-21 3:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-20 21:10 EVIOC mechanism for MT slots Rafi Rubin
2011-01-21 1:45 ` Ping Cheng
2011-01-21 3:57 ` Chris Bagwell [this message]
2011-01-21 7:58 ` Benjamin Tissoires
2011-01-21 9:15 ` Henrik Rydberg
2011-01-21 9:22 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTikksBMW0vcmJOGg8=VPWS3FB6HQQL46R7VotyON@mail.gmail.com' \
--to=chris@cnpbagwell.com \
--cc=chatty@lii-enac.fr \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=pinglinux@gmail.com \
--cc=rafi@seas.upenn.edu \
--cc=rydberg@euromail.se \
--cc=tissoire@cena.fr \
--cc=xorg-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).