Re: [Spca50x-devs] Adding gspca to the mainline kernel
- Date: Tue, 5 Jun 2007 07:54:33 +0400
- From: "Serge A. Suchkov" <Serge.A.S@xxxxxxxxx>
- Subject: Re: [Spca50x-devs] Adding gspca to the mainline kernel
В сообщении от 5 июня 2007 00:04 вы написали:
> On 6/4/07, Michel Xhaard <mxhaard@xxxxxxxx> wrote:
> > > >1. Code accepted into the mainline kernel must meet certain quality
> > > >standards.
> > >
> > > What you mean when you say about "code quality standards" ?
> > :)
> I'm talking mainly about two things: coding style and more general
> overall code structure. The gspca driver has poor coding style in a
> number of ways:
> - too many indentations make the code unreadable (see spca5xx_setMode,
> - code that indents too many times should be moved into a separate function
> - inconsistent indentations (see spca5xx_set_light_freq, which uses
> spaces instead of tabs, like the rest of the code uses)
I'm sorry ;) Just my IDE has such adjustments for my projects.
In my IDE this code style looks pretty good.
hint: Modern IDE allow to change indent style one command ;)
> The gspca driver has poor overall code style as well:
> - the USB IDs and names of webcams should be associated with their
> specific driver code, not contained in a huge list in gspca_core.c;
OK. See http://mgspca.e1.bmstu.ru
Especially mgspcav1-01.00.12-2 and mgspcav2-02.00.20-1
> makes it much easier to figure out which camera uses which driver when
> the USB IDs and names are in the same file as the code that handles
> - the header file abuse I mentioned earlier (see below)
But all it has no attitude to "quality of a code" it concerns to style of the coding introduced by numerous authors of various parts gspca more likely
> > > >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
> Are you saying we need to continue to support v4l1? Why? From what I
> recall, most applications have moved to v4l2 already.
"Most" ??? Name please even 5 applications. AFAIK more ore less well with current versions v4l2 drivers for webcams work only luvcview by Michel and ekiga.
In the others take place to be problems of this or that sort. The basic problem of compatibility with v4l1 consists in absence userspace libraries of proprietary
decoders and here the layer of compatibility with v4l1 which will not help even is available in v4l2
> > > 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 !
> If there is no current subsystem, then we should make one. It seems
> logical to have a webcam subsystem that you could register with to
> utilize standard webcam functions.
We work in this direction. Though speed of work probably not too impresses ;)
In GSPCA in my opinion many architectural problems which were to be solved
as much as possible effectively and elegantly and to be engaged cosmetic refactoring
not having solved these fundamental problems in my opinion waste of time and forces
Serge A. Suchkov
If you hit two keys on the typewriter, the one you don't want
hits the paper.
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