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. Iñaki García Etxebarria wrote: > > Hi everyone, > > There's currently a problem with the V4L2 API regarding the locking of > resources when a streaming capture is being performed. Put the following > scenario: > - Some app opens the VBI device for streaming, the resources are locked. > - A TV app opens the video device, and tries to S_INPUT the device, but > the ioctl fails with -EBUSY (the driver behaves correctly according to > the spec denying the ioctl). The TV app has no way to tell the VBI app > to stop for a moment, even if typically it won't be a great pain for the > VBI app to restart streaming. > Of course, this isn't the only scenario, but it's the most common one. > > The following would fix the problem: > - The VBI app tells the driver that it can handle the "restart" return > code. The high bits of the integer passed to STREAMON can be used for > this, the drivers would only need a minor change, or a new IOCTL can be > created (or S_PARAM can be used, whatever fits best). > - When the TV app calls S_INPUT (S_STD, ...), the opens marked as > low-priority are automagically streamoff'ed, otherwise, if not all > remaining opens in the device are marked as low-priority, the ioctl > fails as usual. > - The VBI app calls DQBUF, unaware of the situation, it gets the > "restart" error code telling that it has been streamed off, and > streamon's again after adapting to the new capture parameters. > > This is for the V4L2 API, the V4L API would need something similar. > > looking forward to any comments, > Iñaki > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
