Hi Hans, Thank you for the set, and my apologies for taking a look only now. On Sun, Sep 21, 2014 at 04:48:18PM +0200, Hans Verkuil wrote: > This patch series adds support for configuration stores to the control > framework. This allows you to store control values for a particular > configuration (up to VIDEO_MAX_FRAME configuration stores are currently > supported). When you queue a new buffer you can supply the store ID and > the driver will apply all controls for that configuration store. > > When you set a new value for a configuration store then you can choose > whether this is 'fire and forget', i.e. after the driver applies the > control value for that store it won't be applied again until a new value > is set. Or you can set the value every time that configuration store is > applied. This does work for video device nodes but not for sub-device nodes which have no buffer queues. Also if you think of using just a value from the closest video buffer queue, that doesn't work either since there could be more than one of those. Most of the time the controls that need to be applied on per-frame basis are present in embedded systems with complex media pipelines where most of the controls are present on sub-device nodes. In other words this approach alone is not sufficient to bind control related configurations to individual frames. For preparing and applying configurations it is applicable. Thinking about the Android camera API v3, controls are a part of the picture only: capture requests contain buffer sets as well. I think the concept makes sense also outside Android. Let's discuss this further at the Media summit. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- 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
