Sound fine to me. If you want help make a new branch in the repo. Or maybe do it anyway just to keep things transparent ;) .
It feels a bit unfair to be forced into gspca but I understand they want to keep things easy to maintain. Three thoughts come to mind: 1. GSPCA was introduced with kernel 2.6.27 . We could make a branch which focusses on supporting older kernels which lack the gspca infrastructure. This would also keep this group useful. Anyone knows how the driver backporting project works? 2. Should some of us subscribe o linux-media or the gspca mailing-list to answer bugreports? After all we still have all the data on and experience with the cams. That would require however that the code and the changes you make are still transparent to us. GWater On 18 Jun., 17:54, Brian Johnson <[email protected]> wrote: > Ok a quick update rather then submit our entire driver it is preferred > to rewrite it as a > gspca subdriver. So i'm currently doing that i've got most of it done > at the moment and > will submit it to linux-media when i finish. There are some stuff that > has been removed > such as sysfs as well as currently the remaining module params. Also > i've dropped the > white-balance control since only a few sensors had that implemented > currently and there > is little reason i can see that you would want to turn it off anyways. > > On Thu, Jun 11, 2009 at 3:47 PM, Josua Grawitter > > <[email protected]> wrote: > > > Am Donnerstag 11 Juni 2009 20:00:47 schrieb Brian Johnson: > > > I've already done the error handling on create_sysfs as well. > > > > I don't really have individual patches against our repository since > > > all these things i've been fixing are based in the six patches against > > > the kernel I'm preparing. I am attaching a patch you can apply to the > > > HEAD of prepare-for-kernel that should sync it against the current > > > kernel codebase I'm using. > > > It seems there really is nothing left to do ;). > > > Anyway upon testing I noticed several things: > > 1. Compiling without evdev fails because of one dev->input_gpio in the probe > > function. It seems this needs an extra > > #ifdef EVDEV_bla > > since sn9c20x_initialize() uses dev->input_gpio directly after that. Maybe > > that part of sn9c20x_initialize should be moved to input_init()? > > > 2. dmesg says that my cam is accessable vie /dev/video1 while it is actually > > using /dev/video0. Has something in the nameing conventions changed? (I use > > Fedora11. They have moved some parts of HAL over to DeviceKit. However I > > don't > > know whether this is caused by HAL at all). > > > Apart from that - great. Let' go fast lane for 2.6.31 ;) > > > GWater --~--~---------~--~----~------------~-------~--~----~ Lets make microdia webcams plug'n play, (currently plug'n pray) To post to this group, send email to [email protected] Visit us online https://groups.google.com/group/microdia -~----------~----~----~----~------~----~------~--~---
