Hi Stan, It's been a long time. How are you doing? :-) On Fri, Feb 10, 2017 at 02:09:42PM +0200, Stanimir Varbanov wrote: > Hi Guennadi, > > On 02/02/2017 08:35 PM, Guennadi Liakhovetski wrote: > > Hi Stanimir, > > > > On Mon, 30 Jan 2017, Stanimir Varbanov wrote: > > > >> Hi Guennadi, > >> > >> On 01/11/2017 11:42 AM, Guennadi Liakhovetski wrote: > > > > [snip] > > > >>> In any case, _if_ we do keep the current approach of separate /dev/video* > >>> nodes, we need a way to associate video and metadata nodes. Earlier I > >>> proposed using media controller links for that. In your implementation of > >> > >> I don't think that media controller links is a good idea. This metadata > >> api could be used by mem2mem drivers which don't have media controller > >> links so we will need a generic v4l2 way to bound image buffer and its > >> metadata buffer. > > > > Is there anything, that's preventing mem2mem drivers from using the MC > > API? Arguably, if you need metadata, you cross the line of becoming a > > complex enough device to deserve MC support? > > Well I don't want to cross that boundary :), and I don't want to use MC > for such simple entity with one input and one output. The only reason to > reply to your email was to provoke your attention to the drivers which > aren't MC based. Do you have a particular use case in mind? We'll need to continue to support two cases: existing hardware and use cases employing the mem2mem interface and more complex hardware that the mem2mem interface is not enough to support: this requires Media controller and the request API. Supposing that we'd extend the mem2mem interface to encompass further functionality, for instance supporting metadata. That functionality would only be available on mem2mem devices. Devices that would not fit to that envelope would have to use MC / request API. Adding more functionality to mem2mem thus will continue to extend two incompatible (when it comes to semantics) APIs within V4L2 and MC interfaces. That forces the driver developer to choose which one to use. (S)he may not be fully aware of the implications of choosing either option, possibly leading to not being able to fully support the hardware with the chosen API. The effect is also similar for applications: they need to support two different APIs. Still, the existing mem2mem framework provides a well defined, easy to use interface within the scope of the functionality it supports. As the MC combined with request API will be a lot more generic, it is also more demanding for applications to use it. The applications are required to, if not know more about the devices, at least be ready to use a number of interfaces to fully enumerate the device's capabilities. > > On other side I think that sequence field in struct vb2_v4l2_buffer > should be sufficient to bound image buffer with metadata buffer. Indeed. With request API, you'll be able to use the request field as well. And that'll work for non-mem2mem devices, too. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx
