Web lists-archives.com

Re: [Spca50x-devs] Adding gspca to the mainline kernel




Le Lundi 4 Juin 2007 08:40, vous avez écrit :
Hi Denver, Serge and all,
> Hi Denver and all.
> I shall afford some remarks on this theme
>
> >1. Code accepted into the mainline kernel must meet certain quality
> >standards.
>
> What you mean when you say about "code quality standards" ?
:)
>
> > The second is lack of support for multiple simultaneously-connected
> > webcams.  From what I can tell, the gspca driver only recognizes one
> > gspca-compatible webcam even if more than one is connected to a given
> > computer.  Usually mainlined drivers will be checked for these sorts
> > of robustness problems prior to inclusion.
Ho Ho !! 
>
> Denver, what you mean in this case ?
> GSPCA work with  multiple simultaneously-connected webcams pretty good.
> Some problems can take place with USB bandwidth, but in this case GSPCA
> driver has the certain advantages in comparison with other webcam drivers
> owing to an opportunity dynamically allocated bandwidth for attached
> devices...see attached screenshot. (it is my modular gspca branch but it
> has on 100% identically working code with original gspca)
look here:
http://mxhaard.free.fr/spca50x/Doc/allinone/four_spca5xxwebcam.jpg

>
> >The third is the abuse of header files to add webcam-specific code.
> >Header files should be used for function declarations, but NOT for
> >function implementations, especially when these implementations are
> >more than one line.  The current .h files should be separated into .h
> >and .c files so the .c files can be compiled into their own object
> >files and then linked together to produce the gspca module.
>
> It is not "code quality" problem. It is only "code style" issue.
Sorry man, i like *.inc file, maybe because i work a lot with assembler :) 
>
> >If we must continue to support v4l version 1, then we can use a method
> >like the ov511 people chose: mainline what you can and keep the
> >decompressor available out of the mainline for those who need it.
Yes, i did not like this. My goal is to provided a working driver not to be 
happy with a really good code, but no one can used ! As i say here, gspca is 
"users centric" NOT "kernel centric" .
 http://www.theinquirer.net/default.aspx?article=39291
>
> In my opinion the basic problems connected with low speed of transition
> from v4l1 to v4l2 just are connected by that decompressor now should is in
> userspace libraries, however it creates the certain problems with backward
> compatibility.
The fourcc method in v4l2 should never works for the ton of proprietary 
compressor, that is my opinion, after 5 years of people waiting this 
wonderfull userspace video library, i am afraid, the concept is wrong ! 
> In this case I consider your offer reasonable.
>
> >If you strongly feel the gspca driver should not be mainlined, please
> >explain why.
I received a lot of mail about that:
What is wrong with GPL code outside the main line kernel ?
Is there only one way togo ? If so what "free" mean ?
>
> Denver, I believe that by the current moment nor gspca nor similar
> subsystems in the mainline kernel have no harmonous, transparent general
> architecture or model of such architecture. Entering gspca a code in a
> kernel in the present kind in my opinion prematurely.
Regards
-- 
Michel Xhaard
http://mxhaard.free.fr

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Spca50x-devs mailing list
Spca50x-devs@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/spca50x-devs