Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755996Ab0HaVvY (ORCPT ); Tue, 31 Aug 2010 17:51:24 -0400 Received: from adelie.canonical.com ([91.189.90.139]:55203 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755964Ab0HaVvW (ORCPT ); Tue, 31 Aug 2010 17:51:22 -0400 Subject: Re: [PATCH 4/6 v2] HID: magicmouse: remove axis data filtering From: Chase Douglas To: Henrik Rydberg Cc: Jiri Kosina , Michael Poole , Tejun Heo , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <4C7D767C.8040607@euromail.se> References: <1283280068-12285-1-git-send-email-chase.douglas@canonical.com> <1283280068-12285-4-git-send-email-chase.douglas@canonical.com> <4C7D6739.5000601@euromail.se> <1283288319.2255.103.camel@mini> <4C7D6ECB.2000308@euromail.se> <1283289360.2255.113.camel@mini> <4C7D71B8.4020408@euromail.se> <1283290078.2255.119.camel@mini> <4C7D767C.8040607@euromail.se> Content-Type: text/plain; charset="UTF-8" Date: Tue, 31 Aug 2010 17:51:09 -0400 Message-ID: <1283291469.2255.129.camel@mini> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3580 Lines: 77 On Tue, 2010-08-31 at 23:39 +0200, Henrik Rydberg wrote: > On 08/31/2010 11:27 PM, Chase Douglas wrote: > > > On Tue, 2010-08-31 at 23:18 +0200, Henrik Rydberg wrote: > >> On 08/31/2010 11:16 PM, Chase Douglas wrote: > >> > >>> On Tue, 2010-08-31 at 23:06 +0200, Henrik Rydberg wrote: > >>>> On 08/31/2010 10:58 PM, Chase Douglas wrote: > >>>> > >>>>> On Tue, 2010-08-31 at 22:34 +0200, Henrik Rydberg wrote: > >>>>>> On 08/31/2010 08:41 PM, Chase Douglas wrote: > >>>>>> > >>>>>>> The Magic Mouse device is very precise. No driver filtering of input > >>>>>>> data needs to be performed. > >>>>>>> > >>>>>>> Signed-off-by: Chase Douglas > >>>>>>> Acked-by: Michael Poole > >>>>>>> --- > >>>>>> > >>>>>> > >>>>>> I am still not sure this is a good idea. Bandwidth from MT devices is a big > >>>>>> deal. A statement roughly how much data comes out of mtdev (which does the > >>>>>> filtering for type A devices) before and after this change would be reassuring. > >>>>> > >>>>> As it is right now, hid-magicmouse doesn't support MT slots. I think all > >>>>> the fuzz code ends up comparing in the MT case is between one touch and > >>>>> another touch, not between one touch's current location and its previous > >>>>> location. If I'm correct, then it means a fuzz > 0 is incorrect for > >>>>> non-slotted MT devices. > >>>>> > >>>>> In fact, the code in drivers/input/input.c around line 194 looks like it > >>>>> discards defuzzing in this case, so one could say this patch is making > >>>>> things more correct :). > >>>> > >>>> > >>>> For type A devices, the filtering is performed in userspace, in mtdev, in the > >>>> same manner as it would have been performed in the kernel in the MT slot case. > >>>> Therefore, knowing the amount of messages coming out of mtdev is a direct > >>>> measurement of the effect of filtering. > >>> > >>> Yes, but we're only interested in the kernel driver when reviewing this > >>> patch. Leaving the fuzz in as it is has no effect right now on ABS_MT_* > >>> axes. On the other axes, such as the touch orientation, it's probably > >>> more harmful than good. > >> > >> > >> "We" are interested in knowing if this patch makes any sense, given that > >> filtering is in actuality performed in userspace, and thus modifying this code > >> changes the stream rate into userspace applications, thank you. > > > > Because in-kernel defuzzing is turned off for ABS_MT_* axes on > > non-slotted MT devices, there will be no change in the number of events > > sent to the userspace due to this patch. > > > > Maybe I'm missing something more fundamental. In which case, I'll need > > more details to get it through my dense skull :). > > > All events passes through to mtdev, yes, but mtdev filters a considerable amount > of events from passing through to X drivers like evdev. Thus, the fuzz values > reported in the kernel driver impacts the performance in userspace, even if > filtering is not done in the kernel. My disconnect was that I didn't understand that the fuzz value in the kernel is exported to userspace. I thought the defuzzing in mtdev was independent of the defuzzing in the kernel. Basically, I don't feel I have the time to do the analysis you want right now. If you really want, I can just remove this change. -- Chase -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/