<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   pinchartl: <u>ndufresne</u>: how would you have liked V4L2 to handle metadata in the ideal case, if not through a separate buffer queue ?
   tfiga: <u>svarbanov</u>: that would be a driver bug
   <br> I believe the protocol is that the application checks for events before dequeuing buffers
   <br> if the driver queues the event before calling vb2_buffer_done() on the buffer, there is no way the event would come later
   svarbanov: yes it is POLLPRI, which means urgent data to read
   <br> yes, ofcourse the driver will push the event in the event queue first. But still on SMP for some reason one cpu could be delayed and by chance this could be a cpu which sending the event. Isn't that possible to happen
   tfiga: Nope
   <br> That should be synchronized in the driver
   <br> Similarly, the userspace should synchronize dequeuing events and buffers
   <br> Typically that would happen in the same thread
   ndufresne: <u>pinchartl</u>: I would have liked a single queue, with a integer telling me the object type, buffer/even/meta/tag whatever
   <br> the kernel got data that arrives together, put then in seperate queues, so they are gone desync and userspace need to resync them, this is a waste of time, plus you are stuck with as many /dev/videoN as there is metadata types
   <br> the seperate queue is just a bad design and will remain in the archives of mistake we did imho
   <br> on that, have a good weekend !
   pinchartl: <u>ndufresne</u>: how would you size the buffers in that case though ?
   <br> bon weekend :-)
   jmondi: <u>mripard</u>: for some definition of fun, yes :)
   ndufresne: <u>pinchartl</u>: I could easily imagine an API similar to event registration, were instead you register buffer type and format, if people likes it, we could even keep the try fmt dance, which as far as I know isn't terrible
   <br> I'm a bit in the line of thinking that if we are going to revisit que v4l2 buffer structure again to unify mplane and non-plane, why we'd oppose to considering a replacement for the queues
   <br> I'm not a kernel dev, so I don't know the inside so well, but I do ear a lot about the internal being less flexible then the API, which seems like a problem for the future, at worst, this discussion can bring ideas for a replacement subsystem
   <br> <u>pinchartl</u>: another turn would be to wave the limitation of the request and let us queue capture buffer for that request (move the capture buffer picking to userspace), to avoid having synchronize the queues, but I think the request is an abstraction on top of queues, and everyone says that fixing a problem by adding a layer of abstraction is
   <br> looking for trouble
   <br> Plus all the problem that might pop if random access in vb2 queue is not a thing, or if the locking is inadequate for that type of usage etc.
   <br> I got more ideas, maybe one around DMA buf heap (like passing the allocator to the driver, instead of passing preallocated buffer) ... Maybe ...
   ***: marvs has quit IRC (Ping timeout: 260 seconds)