> Now as far bttv, this is what I'm seeing in bttv-driver.c (this is in 2.4.17 > with no patches applied): > > case VIDIOCMCAPTURE: > If I read that correctly, it looks like its MCAPTURE ioctl locks the device, > grabs a frame, then unlocks the device. No. It prepeares the buffer the user wants to capture to and puts the buffer into the quere. Starts the bt848-s RISC engine unless it is working already. Then it returns, the application can do something else now. Queuing yet another buffer for example. Next the IRQ handler comes into play. When the current video frame is finished the IRQ handler will activate the buffer, so the bt848 will write the next video frame to the buffer passed by the MCAPTURE ioctl. One frame later the IRQ is raised again, the capture of the frame is done, the IRQ handler will wake up the btv->capq queue and take care to put the next video frame into the next buffer is one is queued. > case VIDIOCSYNC: > Looks to me like the only time the VIDIOCSYNC ioctl will wait is if you are > trying to free the frame that is currently grabbing. Yes, it waits for the hardware finishing the job then (i.e. sleeps on btv->capq). Otherwise there is no need to wait. > If the frame has > already been grabbed (GBUFFER_DONE), the buffer is immediately marked as > unused and the function promptly returns. This happens if you wait long enougth between MCAPTURE and SYNC to allow the hardware being done with the capture already before SYNC is called. > So, if the answer is you call VIDIOCMCAPTURE to queue a frame to be read, and > you call VIDIOCSYNC to wait for the frame to come in... Then the API doc is > not just unclear but arguably completely incorrect, Probably. > the bttv driver looks like it is broken, Why? Gerd -- #define ENOCLUE 125 /* userland programmer induced race condition */
