We found videobuf2-core.h has a function vb2_clear_last_buffer_dequeued to clear last_buffer_dequeued. We call vb2_clear_last_buffer_dequeued in the driver when it gets CMD_START. Everything works now. On Mon, Oct 17, 2016 at 9:46 PM, Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > Le samedi 15 octobre 2016 à 08:16 +0800, Wu-Cheng Li (李務誠) a écrit : >> last_buffer_dequeued is only cleared to false when CAPTURE queue is >> STREAMOFF (#1). Queuing a header to OUTPUT queue won't clear >> last_buffer_dequeued of CAPTURE queue. It looks to me that v4l2 core >> needs to intercept CMD_START and clear last_buffer_dequeued. What do >> you think? We found >> >> http://lxr.free-electrons.com/source/drivers/media/v4l2-core/videobuf2-core.c#L1951 > > That sounds reasonable, assuming it does not break drivers. > >> > >> > >> > Note that for many a flush is the action of getting rid of the pending >> > images and achieve by using STREAMOFF. While the effect of CMD_STOP is >> > to signal the decoder that no more encoded image will be queued, hence >> > remaining images should be delivered to userspace. They will >> > differentiate as a flush operation vs as drain operation. This is no >> > rocket science of course. >> >> I see. What I want is drain operation. In Chromium terms, CMD_STOP >> maps to flush and STREAMOFF maps to reset. > > Yes, that's the reason I was mentioning. This was a great source of > confusion during a workshop with some Google/Chromium folks. > > A question on top of this, what are the use cases for you to drain > without flushing afteward ? Is it really needed ? > > regards, > Nicolas -- 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
