Hi Morimoto-san, On Fri, 30 Jan 2009, morimoto.kuninori@xxxxxxxxxxx wrote: > > > I attached stupid 4 patches. > (snip) > > Thanks for the patches, please, give me a couple of days for review. > (snip) > >> Yes, I'm (going to be) reviewing them, as soon as I find some time. > > If you have not reviewed now, please use attached one. > It use more clever way I think. I'll have to think about it more, but the first impression is - this wouldn't work. At the moment we use the same soc-camera API call set_fmt for both S_FMT and S_CROP calls. But it you look in various instance drivers - host and camera - you will see, that almost all of them have a test "if (pixfmt)," i.e., they have to differentiate between the two cases. And not only because with pixfmt == 0 they cannot configure the stack completely, but because the meaning of these two calls even just with respect to geometry is different: S_FMT specifies scaling, whereas S_CROP preserves the current scaling and only specifies a window using the current scaled coordinates. So, you have to be able to differentiate. The original mt9m001 and mt9v022 drivers didn't support scaling, so, for they just used cropping for both, but the recently added mt9t031 does support scaling, so, it is indeed important. Not sure about mt9m111, and yours ov772x and tw9910. Further, calling set_bus_param() from (or soc_camera_s_fmt_vid_cap()) from S_CROP is not enough too. This lets the capture.c example run, but, I think, we should be able to run with no configuration at all - even without a S_CROP. So, some default configuration has to be set up on open() or on STREAMON if none is set yet (current_fmt == NULL). So, you can either wit until I find time to address this, or try to do something along these lines yourself. But I'm not sure if I manage to propose anything meaningful before FOSDEM (next weekend), so, this might take up to two weeks. But, I think, we have a bit of time before the 2.6.30 merge window:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
