> Maybe it's a consequence of the unprecise API. In bttv, VIDIOCMCAPTURE
> returns immediately after executing some elementary steps. VIDIOCSYNC
> calls interruptible_sleep_on() resp. schedule(), i.e. it blocks.
The API is very clear and what the driver does internally doesn't
matter.
VIDIOCMCAPTURE
asks the driver to capture a frame to a specific buffer.
VIDIOCSYNC
waits until the data for a specific frame is available.
To capture a single frame a application must call both VIDIOCMCAPTURE
and VIDIOCSYNC.
The point of splitting up this into two ioctls is to allow queuing
capture requests and do double-buffering, i.e. stuff like this:
VIDIOCMCAPTURE(0)
for (;;) {
VIDIOCMCAPTURE(1)
VIDIOCSYNC(0)
/* process frame 0 data while DMA xfer to frame 1 is in flight */
VIDIOCMCAPTURE(0)
VIDIOCSYNC(1)
/* process frame 1 data while DMA xfer to frame 0 is in flight */
}
You can do that with more that two buffers too, but in case you are
using bttv you have to tweak the driver (gbuffers insmod option)
because bttv (0.7.x versions) gives you only two buffers by default.
With devices which don't do DMA and expect the CPU doing all the work it
might be that VIDIOCMCAPTURE handles everything and VIDIOCSYNC is
effectively a NOP. But for the application these driver internals don't
matter. You simply call both ioctls and it will work. That is the
point of the v4l API: You don't write applications for bttv. You write
a application for the v4l API, and it should work with all v4l drivers.
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
