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 <chase.douglas@xxxxxxxxxxxxx> >>>>>>> Acked-by: Michael Poole <mdpoole@xxxxxxxxxxx> >>>>>>> --- >>>>>> >>>>>> >>>>>> 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. Henrik -- 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
