Web lists-archives.com

Re: [Spca50x-devs] (Re)design of gspca-v4l2




Jean-Francois Moine wrote:
> On Sun, 30 Mar 2008 11:46:33 +0200, Hans de Goede <j.w.r.degoede@xxxxxx> 
> wrote:
>> Hi All,
> 
> Hi Hans,
> 
> 	[snip]
>> 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.
>>
>> It however also has several big drawbacks:
> 	[snip]
> 
> You are right. In the last version, I changed the code so the transfer
> URB packet to application frame is done at interrupt level. As there is
> no decoding, the overhead is small.
> 

I'm very happy to hear you agree with me and to see the necessary changes in 
version 0.24, that takes away my last reservation for throwing away my own work 
(it was not for nothing I learned a lot from it!) and start working on gspcav2!

Unfortunately I'm rather busy at work the coming 2 days and after that I'm away 
the whole weekendm, but I hope to find enough time to get pac207 up and running 
in gspcav2 next week.




>> Problems with the suggested design: what todo with processing which needs to be 
>> done on the raw isoc packet data before being suitable for userspace.
>>
>> Solutions:
>> 1) Don't, always feed raw data (frame aligned by checking for sof's but
>>   otherwise raw) to userspace.
> 	[snip other solutions]
>> After having written this all down, I believe I've answered my own question 
>> with with regards howto solve the processing of raw data problem, the answer I 
>> believe is method 3.
> 
> I think that only the solution 1 can be done. Decoding the frames is
> the job of the (so awaited) v4l2 library!
> 
> BTW, without this library, a v4l2 helper extension must exist. Instead
> of having a generic helper, as developped by Thierry Merle, I think
> that the (main) gspca driver could implement a particular device, say
> /dev/gspca_ext which could do pixfmt negociation and frame translation
> with specific ioctls.
> 
> An other idea is to develop a usermode driver which uses a
> vloopback-like device and the usblib. Such a driver could re-use the
> same code (hear: without source change, only with a different
> compilation) so that extending the supported webcam set could be easy
> and any video application will work.
> 

I've been thinking about the same (v4l1 emulation with format transformation) 
too, I think this could best be done with a library which can be loaded with 
LD_PRELOAD and which then intercepts the necessary systemcalls (by providing 
symbols like open and ioctl) and does the needed translation, just like oss -> 
alsa wrappers do. I've some experience in writing such libraries.

> Best regards.
> 
> - 
> Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 


Regards,

Hans


p.s.

Something (small) I noticed while looking through the code, in vidioc_qbuf, you 
first check if that the to be queued frame does not have its V4L2_BUF_FLAG_DONE 
set, and then at line 1472 (in 0.24) you clear the V4L2_BUF_FLAG_DONE flag, 
since you already checked that that isn't set clearing it is not necessary.

Don't worry for future changes I'll send proper patches, any chance you could 
set up some kind of VCS soon, that would make keeping our work synced easier.


-------------------------------------------------------------------------
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. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Spca50x-devs mailing list
Spca50x-devs@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/spca50x-devs