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]
Message-ID: <Pine.LNX.4.64.1106012128080.29934@axis700.grange>
Date:	Wed, 1 Jun 2011 21:35:17 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Andrew Chew <AChew@...dia.com>
cc:	"mchehab@...hat.com" <mchehab@...hat.com>,
	"olof@...om.net" <olof@...om.net>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 4/5 v2] [media] ov9740: Remove hardcoded resolution regs

On Tue, 31 May 2011, Andrew Chew wrote:

> > > +	/* Width must be a multiple of 4 pixels. */
> > > +	*width += *width % 4;
> > 
> > No, this doesn't make it a multiple of 4, unless it was 
> > even;) Just take 5 
> > as an example. What you really want here is
> 
> Geez, you're right.  Not sure what was going on in my head when I did this.  Thanks for catching it.
> 
> 
> > > +	/*
> > > +	 * Try to use as much of the sensor area as possible 
> > when supporting
> > > +	 * smaller resolutions.  Depending on the aspect ratio of the
> > > +	 * chosen resolution, we can either use the full width 
> > of the sensor,
> > > +	 * or the full height of the sensor (or both if the 
> > aspect ratio is
> > > +	 * the same as 1280x720.
> > > +	 */
> > > +	if ((OV9740_MAX_WIDTH * height) > (OV9740_MAX_HEIGHT * width)) {
> > > +		scale_input_x = (OV9740_MAX_HEIGHT * width) / height;
> > > +		scale_input_y = OV9740_MAX_HEIGHT;
> > >  	} else {
> > > -		dev_err(&client->dev, "Failed to select resolution!\n");
> > > -		return -EINVAL;
> > > +		scale_input_x = OV9740_MAX_WIDTH;
> > > +		scale_input_y = (OV9740_MAX_WIDTH * height) / width;
> > >  	}
> > 
> > I don'z know how this sensor works, but the above two divisions round 
> > down. And these are input sizes. Cannot it possibly lead to 
> > the output 
> > window being smaller, than required? Maybe you have to round 
> > up (hint: 
> > use DIV_ROUND_UP())?
> 
> The intention is to do some ratio math without floating point 
> instructions,

Of course, DIV_ROUND_UP is integer maths only too, as well as (almost) all 
maths in the kernel.

> which resulted in some algebraic twiddling (which is why 
> that math looks so weird).

No, it doesn't look weird, I just wasn't sure, whether your maths would 
work in all situations. The only difference between yours and mine, is 
that yours rounds down, and mine rounds up. So, I'm not sure which one is 
better in this case.

> I think what's there is okay.  If there's 
> any rounding at all (and there shouldn't be any rounding, if "standard" 
> image dimensions are called for), then there's going to be some aspect 
> ratio weirdness no matter which way you round that division.

No, you should be prepared to handle all possible crazy resolution 
requests.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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