lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 31 Aug 2010 16:58:39 -0400
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Jiri Kosina <jkosina@...e.cz>, Michael Poole <mdpoole@...ilus.org>,
	Tejun Heo <tj@...nel.org>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6 v2] HID: magicmouse: remove axis data filtering

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@...onical.com>
> > Acked-by: Michael Poole <mdpoole@...ilus.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 :).

Now a fuzz > 0 for the non-MT ABS axes may be useful, but this device
exhibits no jitter, and we're not really worried about bandwidth in the
single touch case.

-- Chase

> >  drivers/hid/hid-magicmouse.c |   10 +++++-----
> >  1 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > index 98bbc53..0fe2464 100644
> > --- a/drivers/hid/hid-magicmouse.c
> > +++ b/drivers/hid/hid-magicmouse.c
> > @@ -357,11 +357,11 @@ static void magicmouse_setup_input(struct input_dev *input, struct hid_device *h
> >  		__set_bit(EV_ABS, input->evbit);
> >  
> >  		input_set_abs_params(input, ABS_MT_TRACKING_ID, 0, 15, 0, 0);
> > -		input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0, 255, 4, 0);
> > -		input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0, 255, 4, 0);
> > -		input_set_abs_params(input, ABS_MT_ORIENTATION, -32, 31, 1, 0);
> > +		input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
> > +		input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0, 255, 0, 0);
> > +		input_set_abs_params(input, ABS_MT_ORIENTATION, -32, 31, 0, 0);
> >  		input_set_abs_params(input, ABS_MT_POSITION_X, -1100, 1358,
> > -				4, 0);
> > +				0, 0);
> >  		/* Note: Touch Y position from the device is inverted relative
> >  		 * to how pointer motion is reported (and relative to how USB
> >  		 * HID recommends the coordinates work).  This driver keeps
> > @@ -369,7 +369,7 @@ static void magicmouse_setup_input(struct input_dev *input, struct hid_device *h
> >  		 * inverse of the reported Y.
> >  		 */
> >  		input_set_abs_params(input, ABS_MT_POSITION_Y, -1589, 2047,
> > -				4, 0);
> > +				0, 0);
> >  	}
> >  
> >  	if (report_undeciphered) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ