Re: [Spca50x-devs] (Re)design of gspca-v4l2
- Date: Wed, 09 Apr 2008 23:20:45 +0200
- From: Hans de Goede <j.w.r.degoede@xxxxxx>
- Subject: Re: [Spca50x-devs] (Re)design of gspca-v4l2
Mauro Carvalho Chehab wrote:
> On Sun, 30 Mar 2008 11:46:33 +0200
> Hans de Goede <j.w.r.degoede@xxxxxx> wrote:
>> Hi All,
>> I've been thinking some more (a lot more) about the current gspca-v4l2 design,
>> and I'm sad to say that I believe that after all it is not such a good design.
>> The current design, which queues urbs for later processing in the application
>> kernel context when a read or dqbuf call is made. Has one big advantage, the
>> urb_complete handler which gets called in bottom half interrupt context is
>> extremely short.
> Sorry for being late on discussing this. I'm flooded of work here.
> Unfortunately, I didn't analyse yet gspca v2 or pac207.
> Yet, let me give my personal oppinions about the issues you've commented on this
> 1) the better is really to do frame conversions at userspace. the LD_PRELOAD
> approach seems something interesting, while we don't have a more generic
> solution. Frame conversions on kernelspace, during IRQ time is something ugly
> and may produce all sorts of troubles;
> 2) it seemed that both drivers are implementing their own framebuffer control.
> The better, IMO, is to use videobuf-vmalloc. We are putting lots of effort to
> analyse locks inside it, and to optimize its code. This will provide a very
> nice framework for all USB drivers. Currently, we are working on two or three
> drivers to use it. Please, feel free to use it, test, and improve ;)
Hmm, I've just been reviewing / auditing Jean-Francois' newest gspca v2 code,
and he has a nice _lockless_ implementation in there for buffeeeer management.
With usb there is always only one producer and one can force one consumer with
regular locking on the reader side, so one can work lockless in the urb
completion handler, so no spinlocks in the irq handler!
All in all usbvideodev core seems like a bit of overkill, and its not lockless :)
So I prefer to continue with what we have now, and then maybe later convert
this to videobuf-vmalloc, this should not be too hard, as all the buffer
handling is in one central place and thus will be shared by all webcam drivers
which are part of gspca. Then again, can you give an example of an usb webcam
driver currently using videobuf, then I can take a look at how its used there,
and if that would be good for us.
> 3) From what I understood, both Hans and Jean-Francois agreed that it would be
> nice to merge pac207 and gspca v2. IMO, this is the better to do. Having
> several separate drivers doing about the same thing is bad, since a bug fixed
> into one driver can still affect the others. From maintenance POV, having a
> common code shared by several drivers is generally makes the code simpler,
> helping to fix bugs faster.
Yes, I'll be merging my work into Jean-Francois' work.
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Spca50x-devs mailing list