On Mon, Oct 12, 2009 at 3:33 AM, Mattias Persson <d9...@yahoo.se> wrote: > Hi, >
Please send messages to the new mailing list: linux-media@vger.kernel.org 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
