On 1/6/2011 7:33 AM, Laurent Pinchart wrote:
Hi everybody,
...
The OMAP3 ISP resizer currently implements the second option, and I'll modify
it to implement the first option. The drawback is that some crop/output
combinations will require an extra step to be achieved. I'd like your opinion
on this issue. Is the behaviour described in option one acceptable ? Should
the API be extended/modified to make it simpler for applications to configure
the various sizes in the image pipeline ? Are we all doomed and will we have
to use a crop/scale API that nobody will ever understand ? :-)
I'm personally a big fan of having some way to atomically set multiple
settings at once, exactly to avoid these sorts of problems. The
fundamental problem here is that the interface implicitly assumes that
every intermediate state has to be a valid one, when during device
configuration most states are transitory because the application hasn't
finished configuring the pipeline/sensor/etc, and the state shouldn't
get vetted and adjusted until the configuration is complete. The
VIDOC_S_EXT_CTRLS seems like a reasonable solution - can't something
like that apply to the subdev interfaces? (Or am I missing something
beyond that?)
Similar issues have cropped up for us with other interdependent settings
like exposure time/frame duration, or the cropping/scaling options found
directly on the mt9p031 sensor, which are quite analogous to your issue
- there's 1-4x scaling and a selectable ROI, which interact, especially
during streaming when a constant output size has to be maintained. What
I ended up doing was effectively hacking in an atomic control update
procedure for the old v4l2_int_device stuff (very hacky), but then I
didn't have to worry about it any more.
In general, I'd be worried if executing the same stream of control
updates in a different order gave a different final result. With atomic
updates, you'd still have to decide how to round to the closest valid
state, but at least it'd be consistent.
Regards,
Eino-Ville Talvala
Stanford University
--
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
