Benedict Bridgwater wrote: > > Justin Schoeman wrote: > > > > This is incorrect: VIDIOCSYNC isn't used to free a buffer after it has been used, but > > > rather to wait for it to be filled by the driver. > > > > Actually, the API document is correct, just a little vague! CSYNC does > > free the buffer (in that it removes it from internal capture queues. > > The API spec also fails to mention that if the buffer is in use CSYNC > > will block until it is free (which has the side-effect of waiting until > > the buffer is filled by the driver). > > No, Justin - it's wrong. > > VIDIOCSYNC is not called *after* a buffer has been used... it has to be > called *before* it can be used. Black/White - see the difference? Just wrong point of view - the API is talking from a driver point of view i.e. CSYNC frees it from the driver queue, making it available for the application. So yes, the application MUST call CSYNC before using the buffer, but the API document remains correct (if you understand its rather vague point of view). > > > Also, the comment about setting image > > > size/depth before capture appears to apply to overlay, not mmap capture... certainly for > > > the bttv driver it's incorrect - if you look at the bttv source (or any working > > > application!) you'll see that SPICT/SWIN apply to overlay only and that what's used for > > > mmap capture are the MCAPTURE values. > > > > Just because it works does not meen it is right - this is bttv specific > > (and has been adopted by some other vide drivers), and is not guaranteed > > to work with all v4l drivers. I have just confirmed with Alan Cox that > > the v4l API REQUIRES the SWIN ioctl before the GMBUF ioctl - > > applications which don't do this may work, but they are not v4l > > compliant. > > Overlay and capture are meant to be independent. Just because I'm doing > a (say) 320x240 overlay shouldn't prevent me from doing a 640x480 > capture, which is what you are saying. If the API was meant to tie > overlay and mmap capture together in that way, then that's a bad API, > and it's just as well the drivers never implemented that restriction! They are indeed independant. The only restriction is that the window size (as set by SWIN) before a call to GMBUF, must be the same size, or bigger, than the largest image you intend to capture. After the call to GMBUF you can SWIN as much as you want without affecting capture. > If you're proposing to "fix" bttv to add this restriction, or maybe for > other drivers to add it, then you're going to break a lot of existing > applications, or make it so that they can only run on bttv. If you want > the application to be able to restrict the amount of memory the driver > needs to allocate for mmap, then a saner way to do it would be to > introduce a new ioctl for that purpose, and for the sake of backward > application compatability say that if the app hasn't called the ioctl > between open and mmap then max size is implicit. (or just use V4L2) I am not proposing to fix any drivers. What I am proposing is to fix APPLICATIONS. It will cost the application developer very little to add the one ioctl, which will ensure that the application then works on any v4l compliant driver. Two other alternatives: 1) (The way we are heading now) Declare a new API spec, for example "bttv", and say these drivers and applications are "bttv" compliant". 2) Propose a cleaner ioctl to Alan, and see if he will accept it. Personally, I really hate to see people trampling all over an API spec, just because the most popular driver chose to take a shortcut, and most application developers just develope for this driver (rather than the API itself). In the end, if you don't like it, fix it - don't just ignore it (or we may end up with a Microsoft clone ;-( ). -justin
