Re: frame buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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?

> > 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!

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)

Ben





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux