On Thu, Jan 20, 2011 at 7:45 PM, Ping Cheng <pinglinux@xxxxxxxxx> 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@xxxxxxxxx> > To: Ping Cheng <pinglinux@xxxxxxxxx> > CC: Henrik Rydberg <rydberg@xxxxxxxxxxx>, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx>, linux-input@xxxxxxxxxxxxxxx, > linux-kernel@xxxxxxxxxxxxxxx, Mika Kuoppala <mika.kuoppala@xxxxxxxxx>, > Peter Hutterer <peter.hutterer@xxxxxxxxx>, Benjamin Tissoires > <tissoire@xxxxxxx>, Stephane Chatty <chatty@xxxxxxx>, Rafi Rubin > <rafi@xxxxxxxxxxxxxx>, Michael Poole <mdpoole@xxxxxxxxxxx> > > > 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
