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
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
