Re: [Spca50x-devs] Adding gspca to the mainline kernel
- Date: Mon, 4 Jun 2007 18:44:38 +0200
- From: Michel Xhaard <mxhaard@xxxxxxxx>
- Subject: 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
> 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)
> >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
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.
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