On Mon, 29 Aug 2011, Laurent Pinchart wrote: > Hi Guennadi, > > On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote: > > On Mon, 29 Aug 2011, Laurent Pinchart wrote: > > > On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote: > > > > On Sun, 28 Aug 2011, Laurent Pinchart wrote: > > > > > > > > [snip] > > > > > > > > > > @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev > > > > > > *sd, > > > > > > > > > > > > ov5642_try_fmt(sd, mf); > > > > > > > > > > > > + priv->out_size.width = mf->width; > > > > > > + priv->out_size.height = mf->height; > > > > > > > > > > It looks like to me (but I may be wrong) that you achieve different > > > > > resolutions using cropping, not scaling. If that's correct you should > > > > > implement s_crop support and refuse changing the resolution through > > > > > s_fmt. > > > > > > > > As the patch explains (I think) on several occasions, currently only > > > > the 1:1 scale is supported, and it was our deliberate choice to > > > > implement this using the scaling API > > > > > > If you implement cropping, you should use the crop API, not the scaling > > > API > > > > > > :-) > > > > It's changing both - input and output sizes. > > Sure, but it's still cropping.
Why? Isn't it a matter of the PoV? It changes the output window, i.e., implements S_FMT. And S_FMT is by far more important / widely used than S_CROP. Refusing to change the output window and always just returning the == crop size wouldn't be polite, IMHO. Don't think many users would guess to use S_CROP. Standard applications a la mplayer don't use S_CROP at all. 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
