On 10/09/14 13:55, Sakari Ailus wrote: > 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. The subdevices may not have buffer queues, but the high-level media driver will know when a subdevice has to apply a specific configuration store and can tell the subdev to do so. That's the way I expect it to work. > 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. Good point. One solution might be to allow for a larger range of config store IDs (i.e., more than just 1-32, where 32 is the current maximum number of buffers). That way different buffer queues can use unique config store IDs. This does make the internal data structures a bit more complex, but it's not a big deal. > > 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. Let's do that. Regards, Hans -- 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
