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:

> >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" .
> 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.
Michel Xhaard

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.
Spca50x-devs mailing list