Quoting Joe Burks <joe-v4l@xxxxxxxxxxx>: > The only problem I have with this is that the drivers will flag an error if > you VIDIOCSYNC a frame twice, even though the second time the driver still > isn't using it. The drivers I've seen have two flags: One which says "I've > read the data, it is sitting in the mmap buffer, but the user hasn't SYNCed > it", and another which says "I've read the data, it is sitting in the mmap > buffer, and user has SYNCed it". The only purpose of this flag seems to be > to allow an error to be returned if SYNC is done twice on a buffer before > 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. The driver should check for the duplicated VIDIOCSYNCs simply because some devices may fill the buffer *during* the time period between MCAPTURE and SYNC, and they may set semaphores accordingly. In worst case, if you issue the second SYNC the driver could be waiting on a semaphore that noone is going to post (because the matching MCAPTURE was never issued). It is only logical that drivers protect themselves, as they should. The API, as published, is clear: the frame state before MCAPTURE is undefined; after MCAPTURE but before SYNC it is being used, and you shall not read the memory because it is driver-dependent at this point. After the SYNC returns, you have your frame, and it is yours until you issue another MCAPTURE into this frame. However usage of chain of buffers is less clear. The API does not state that the driver can/shall/will *automatically* direct new data into the next ready buffer. The worst case is the order of buffers. What if they are submitted (with MCAPTURE) out of sequence? In what order they will be returned, if SYNC order does not match the submission order? This depends, obviously, on the implementation of the driver (when the data flows into the buffer). Dmitri -- Yesterday upon the stair, I saw a man who wasn't there. He wasn't there again today; I think he's from the CIA. - David Rodenhiser
Attachment:
pgpgrZ7dEOTL2.pgp
Description: PGP signature
