Bill Dirks wrote: > > That is a good point. > > I've thought about what you said, and the general problem is that there > is no concept of a stream halt except by explicit STREAMOFF command from > the program. V4L2 needs to handle the case where a stream has to be > halted because of an external event or change-of-state on the hardware. > > Your example is good, but any stream could be interrupted, and it may > not be possible to restart the stream. For example, a hot-pluggable > device that gets unplugged. I think we just need a clean way for a > driver to halt a stream and let the app know that happened. > > So I propose the following: > > If the driver internally halts a stream, then VIDIOC_DQBUF will return > -ERESTART. If the app gets -ERESTART then the app must do a > VIDIOC_STREAMOFF (to clear the driver state). Because the state of the > hardware may have changed, the application must re-set the capture > format, and possibly munmap and re-acquire the buffers before restarting > the stream. > > With that, it is possible to make things like changing input or changing > the norm (NTSC/PAL) work. Plus we have a clean way to handle > disconnections or any kind of hardware exception condition. Comments? > > Bill. It would still be a good idea to be able to flag streams as interruptible - or maybe this should be something specific to the multiple opens spec? In fact, would it be possible to get Gerd's multiple open spec officially included in the v4l2 API (http://www.strusel007.de/linux/bttv/multiple-opens.html). In this spec you can see that any streaming open locks down the input and associated resources. Sometimes this is definitely not wanted (eg VBI streaming), and we would want to be able to explicitly flag it as interruptible. Thanks -justin
