On Friday 15 February 2002 04:17 pm, Trent Piepho wrote: > The application needs to queue up frames to be captured, since otherwise > how would the driver know that the application is done with the buffer? That was exactly the confusion created by the bad doc. It (the API doc) says that calling VIDIOSYNC tells the driver that the application is done with the buffer. > > MCAPTURE is called. The semantic of SYNC would seem to be "block until > > you're done with this frame", but it only works once. Even though it is > > still done with the frame the second time, it returns -EINVAL. > > But why would you want to sync on the same frame twice? I can't think of a reason to sync twice any more than I can think of a reason to return an error on the second sync. Since I'm trying to write a driver the semantics of these things are ones I would hopefully understand. > The of the flag as meaning, > "buffer full, owned by driver" (not yet synced) > vs > "buffer full, owned by application" (synced) > > Now, I suppose that for most drivers there really isn't a difference > between these two states, and the only purpose of the flag is cause an > error if the application tries to sync a buffer that is already synced. > But there is a conceptual difference between these states, and I could > imagine a driver that cares. For instance the "owned by driver" state > could have the memory readable by the kernel, but not by userspace. The > "owned by application" state would change the ownership (segment, etc.) of > the memory. With the way the mmap stuff works, could you do this? The application is (I think) supposed to provide the memory that the driver writes to. All the buffers are supposed to be in one contiguous block of memory. -Joe
