Re: How to store the latest image without modifying videobuf-core.c

On Mon, Oct 12, 2009 at 3:33 AM, Mattias Persson <[email protected]> wrote:
> Hi,
>

Please send messages to the new mailing list:
[email protected] from now on.

> I am developing a driver for a camera. As an example I am using the vivi driver (2.6.28) and the first major difference between my ISR and thread_tick() is that my driver will always attempt to store the latest image, even if nobody is waiting for a new image.

I believe the standard here is that your driver should simply drop the
frame if no one is waiting for it.
>
> In my driver, when all queued buffers are used any new images will be stored in the oldest frame which has already been captured (state == VIDEOBUF_DONE) and here is where my problems start. (If this is wrong, what shall I do to always keep the latest captured image?)
>

If no one wants the image you should just drop it but note that it
existed. I believe the v4l2 api has frame counters so that the
application knows that it missed some.

> In the function videobuf_dqbuf in videobuf-core.c, if a new image is returned by stream_next_buffer and the ISR kicks in before videobuf_dqbuf can set buf->state to VIDEOBUF_IDLE, my driver will modify the image presented to userspace and that is not acceptable.

Correct, it's not acceptable to modify userspace memory when not asked to do so.

>
> The only solution I can find is to use the spinlock in videobuf_queue when the userspace application is requesting a new image (DQBUF/poll) to check for a new image and set some flag indicating that the buffer can't be overwritten by the ISR. However, this approach would require changes to videobuf-core.c and that doesn't seem right. Can someone please give me some guidance on this?
>
> Regards,
> Mattias

You might want to take a look at possibly using gspca as a base for
your driver. It currently supports hundreds of cameras and there are
quite a few drivers that you can use as a reference. gspca doesn't use
videobuf.. but should make it less painful to write a driver.

Regards,

David Ellingsworth

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list