Hi Hans, > -----Original Message----- > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > Sent: Thursday, April 11, 2013 11:41 AM > To: k.debski@xxxxxxxxxxx > Cc: linux-media@xxxxxxxxxxxxxxx; Tzu-Jung Lee > Subject: Exact behavior of the EOS event? > > Hi Kamil, Roy, > > When implementing eos support in v4l2-ctl I started wondering about the > exact timings of that. > > There are two cases, polling and non-polling, and I'll explain how I do > it now in v4l2-ctl. > > Polling case: > > I select for both read and exceptions. When the select returns I check > for exceptions and call DQEVENT, which may return EOS. > > If there is something to read then I call DQBUF to get the frame, > process it and afterwards exit the capture loop if the EOS event was > seen. > > This procedure assumes that setting the event and making the last frame > available to userspace happen atomically, otherwise you can get a race > condition. > > Non-polling case: > > I select for an exception with a timeout of 0 (i.e. returns > immediately), then I call DQBUF (which may block), process the frame > and exit if EOS was seen. > > I suspect this is wrong, since when I call select the EOS may not be > set yet, but it is after the DQBUF. So in the next run through the > capture loop I capture one frame too many. > > > What I think is the correct sequence is to first select for a read(), > but not exceptions, then do the DQBUF, and finally do a select for > exceptions with a timeout of 0. If EOS was seen, then that was the last > frame. > > A potential problem with that might be when you want to select on other > events as well. Then you would select on both read and exceptions, and > we end up with a potential race condition again. The only solution I > see is to open a second filehandle to the video node and subscribe to > the EOS event only for that filehandle and use that to do the EOS > polling. This would work if we have a single context only. In case of mem2mem devices, where there is a separate context for each file this would not work. > > It all feels rather awkward. > > Kamil, Roy, any ideas/suggestions to improve this? > > Regards, > > Hans -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
