lkml.org 
[lkml]   [2010]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 4/6 v2] HID: magicmouse: remove axis data filtering
From
Date
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 <chase.douglas@canonical.com>
> >>>>>>> Acked-by: Michael Poole <mdpoole@troilus.org>
> >>>>>>> ---
> >>>>>>
> >>>>>>
> >>>>>> 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



\
 
 \ /
  Last update: 2010-08-31 23:53    [W:0.057 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site