On Fri, 10 Feb 2017, 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. Would be nice to hear others' opinions. > On other side I think that sequence field in struct vb2_v4l2_buffer > should be sufficient to bound image buffer with metadata buffer. How can that be helpful? Firstly you have to be able to find node pairs without streaming. Secondly, you don't want to open all nodes and try to dequeue buffers on them to find out which ones begin to stream and have equal sequence numbers. Thanks Guennadi > -- > regards, > Stan
