From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Tissoires Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots Date: Thu, 27 May 2010 09:08:10 +0200 Message-ID: <4BFE1A5A.8010802@cena.fr> References: <1274788379-11026-1-git-send-email-rydberg@euromail.se> <20100525173446.GA4634@core.coreip.homeip.net> <4BFC2A7D.50501@euromail.se> <20100525202340.GD4455@core.coreip.homeip.net> <20100527070310.GC17625@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp1-g21.free.fr ([212.27.42.1]:56706 "EHLO smtp1-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756626Ab0E0HKS (ORCPT ); Thu, 27 May 2010 03:10:18 -0400 In-Reply-To: <20100527070310.GC17625@core.coreip.homeip.net> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Dmitry Torokhov Cc: Ping Cheng , Henrik Rydberg , Andrew Morton , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Kuoppala , Peter Hutterer , Stephane Chatty , Rafi Rubin , Michael Poole Le 27/05/2010 09:03, Dmitry Torokhov a =E9crit : > On Wed, May 26, 2010 at 08:59:35AM -0700, Ping Cheng wrote: >> On Tue, May 25, 2010 at 1:23 PM, Dmitry Torokhov >> 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 stat= e >>>>>> 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 ext= racted >>>>>> with calls to EVIOCGABS. >>>>>> >>>>>> The symmetric operation, to set the MT state via EVIOCSABS, seem= s to >>>>>> violate input data integrity, and is therefore not implemented. >>>>>> >>>>> >>>>> This looks sane, however the question remains - is there any user= s 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 multitou= ch 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 n= ot 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, t= he >> 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 qualit= y >> :), it filtered all the noises so we can not locate the touch withou= t >> 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 d= id >> for the existing input devices. At least, it doesn't hurt to make th= e >> 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 i= t. > However if no one using this - why should we bother? Will _you_ utili= ze > this functionality in Wacom X driver? If so let me know and I will me= rge > it. > Hi Dmitry, I'm the guy who submitted some patchs to enable multitouch in the=20 xf86-input-evdev driver. And I think that I will use the MT_SLOTS as=20 soon as they are available. It is much easier for the upper part to hav= e=20 this protocol instead of the protocol type A. You can count me with as a user of this new protocol and whatever relat= ed. Cheers, Benjamin -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756899Ab0E0HKU (ORCPT ); Thu, 27 May 2010 03:10:20 -0400 Received: from smtp1-g21.free.fr ([212.27.42.1]:56706 "EHLO smtp1-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756626Ab0E0HKS (ORCPT ); Thu, 27 May 2010 03:10:18 -0400 Message-ID: <4BFE1A5A.8010802@cena.fr> Date: Thu, 27 May 2010 09:08:10 +0200 From: Benjamin Tissoires User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dmitry Torokhov CC: Ping Cheng , Henrik Rydberg , Andrew Morton , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Kuoppala , Peter Hutterer , Stephane Chatty , Rafi Rubin , Michael Poole Subject: Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots References: <1274788379-11026-1-git-send-email-rydberg@euromail.se> <20100525173446.GA4634@core.coreip.homeip.net> <4BFC2A7D.50501@euromail.se> <20100525202340.GD4455@core.coreip.homeip.net> <20100527070310.GC17625@core.coreip.homeip.net> In-Reply-To: <20100527070310.GC17625@core.coreip.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 27/05/2010 09:03, Dmitry Torokhov a écrit : > On Wed, May 26, 2010 at 08:59:35AM -0700, Ping Cheng wrote: >> On Tue, May 25, 2010 at 1:23 PM, Dmitry Torokhov >> 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. > Hi Dmitry, I'm the guy who submitted some patchs to enable multitouch in the xf86-input-evdev driver. And I think that I will use the MT_SLOTS as soon as they are available. It is much easier for the upper part to have this protocol instead of the protocol type A. You can count me with as a user of this new protocol and whatever related. Cheers, Benjamin