I'd like to re-open the discussion into mainlining the gspca driver
because I feel there are some aspects of the discussion that haven't
been dealt with much. I've searched the list archives for past
discussions so hopefully there isn't too much repeat here (and if
there is, I'm intentionally quoting someone).
Based on my own experiences with the driver, including delving into
the code, here are the main reasons I see for mainlining the kernel
(in approximate order of importance):
1. Code accepted into the mainline kernel must meet certain quality
standards. Attempting to mainline the gspca driver would be met with
many suggestions for how to improve the code, allowing us to improve
the driver.
There are several issues pertaining to code quality that I have seen
in the gspca driver. The first is broken support for older hardware.
According to Michel, the gspca driver (spca50x at the time) used to
support composite video in on the CS430, but that functionality is
broken as I found out when I tried to use it with my CS430 webcam. If
the gspca driver had more stringent requirements on code submissions
as the Linux kernel does, these sorts of issues would be less likely
to occur.
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.
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.
Certainly all of the above code quality problems could be fixed
without mainlining the gspca driver. However, maintaining a high
level of code quality would best be done by adding the driver to the
mainline kernel because the kernel maintainers tend to demand
high-quality code.
I am not trying to say that the current code is horrible and
unmaintainable. I can see the reasons for not demanding the same
level of quality that the kernel people demand. Doing so makes
development move faster (people want their webcams working right
away), but it does lead to some crufty code that needs refactoring.
2. The gspca driver will benefit from kernel-wide fixes, such as
interface updates.
This is a common reason for mainlining any driver. An example of how
this would help the gspca driver is in the move from v4l to v4l2. The
onus for making the interface update would be shared between the gspca
maintainers and more general kernel maintainers; right now, the gspca
maintainers alone must make the interface update.
3. Distribution maintainers do not need to worry about including a
gspca package in their distribution.
Currently, in order to provide full webcam support for their users,
distribution maintainers need to maintain a gspca package to include
with their distribution. If the gspca driver were mainlined, this
would give distribution maintainers one less package to worry about
(since the gspca driver would effectively be included in their kernel
package), reducing their workload.
Of course there are also problems to overcome in order to mainline the
driver. I think some of these problems have been framed as barriers
that totally vent the driver from being mainlined, but I don't
think that has to be the case. Here are some problems with mainlining
the kernel along with suggestions for overcoming them:
A. The development pace of the gspca driver is much faster than that
of the mainline kernel. Kernel submission procedures are too
restrictive and would vent new webcams from being supported in a
timely fashion. [1] [2]
I don't think this is entirely true. Another webcam driver, the ov511
driver (http://ovcam.org/ov511/), has code in the kernel that is only
one minor release behind their most recent version, suggesting that
their changes are usually accepted in a timely manner by the kernel
people. I think we should at least consider doing things the way the
ov511 people do.
B. JPEG decoding is not allowed in the kernel and the gspca driver has
to include a JPEG decoder. [1] [3] [4]
This may be the case with the first version of v4l because some
webcams send JPEG data over USB and v4l requires data from the kernel
to be in uncomssed form. However, v4l2 allows drivers to pass JPEG
data directly to user space [5] [6] so this argument is no longer
valid. Most applications that use v4l have switched to v4l2 so it
would make sense for gspca to do the same (I understand this is
already in the works).
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
decomssor available out of the mainline for those who need it.
Here's what I suggest as a course of action:
1. Refactor the gspca driver so it works more like a Linux subsystem
(see drivers/leds in the Linux kernel
(http://lxr.linux.no/source/drivers/leds/) for a simple example of
such a subsystem)
- this would involve having each type of camera register itself with
the gspca core, which would provide some common functionality each
camera needs
- it would be good to see if over webcam projects, like ov511,
already have a subsystem setup which we could plug into or model our
new subsystem after
2. Fix up whatever other problems were not solved by the refactoring
(ie. add support for multiple simultaneously-connected web cams, make
everything work with v4l2)
3. Submit the code to the appropriate list (perhaps linux-usb-devel
would be the correct one, but I'm not entirely sure)
I am willing to help out with these efforts (as time permits), but I'd
need some support. If more people working on the gspca driver feel
that the driver should be mainlined, then I would be inclined to start
this process. But if few people are in support of the idea, it
doesn't make much sense to proceed.
If you strongly feel the gspca driver should not be mainlined, please
explain why. I think it's important that we get some good discussion
going on about this issue because it would mean an important change of
focus for the driver.
Denver
References:
1. Comments from Tomas Groth on mainlining the driver -
http://sourceforge.net/mailarchive/message.php?msg_id=20060720124839.64364.qmail%40web34707.mail.mud.yahoo.com
2. Comments from Michel Xhaard on freedom of current model -
http://mxhaard.free.fr/sview.html (see "Overview", paragraph 2)
3. Comments from Thomas Schorpp quoting Michel Xhaard as saying JPEG
decoder won't make it into kernel -
http://sourceforge.net/mailarchive/message.php?msg_name=450D3EC7.7090609%40gmx.de
4. First question in OV519 section suggests JPEG decoder in kernel is
impossible - http://ovcam.org/ov511/faq.html
5. v4l2 supports JPEG through the V4L2_PIX_FMT_JPEG option -
http://royale.zerezo.com/forum/viewtopic.php?p=418
6. Specification for v4l2 showing JPEG support -
http://v4l2spec.bytesex.org/spec-single/v4l2.html#STANDARD
|
