Email Archive: spca50x-devs (read-only)
|
[Spca50x-devs] Adding gspca to the mainline kernel
From: Denver Gingerich <denver@os...> - 2007-06-04 02:28
|
|
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 prevent 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 prevent 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 uncompressed 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 decompressor 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 |
Thread View
| Thread | Author | Date | |
|---|---|---|---|
| [Spca50x-devs] Adding gspca to the mainline kernel | Denver Gingerich <denver@os...> |
|
|
|
|
|
|
