On Wed, 10 Aug 2011, Alan Stern wrote: > On Tue, 9 Aug 2011, Hans de Goede wrote: > > > Hi, > > > > On 08/09/2011 04:19 PM, Alan Stern wrote: > > > On Tue, 9 Aug 2011, Hans de Goede wrote: > > > According to Theodore, we have developed 5 drivers for them because the > > > stillcam modes in different devices use four different vendor-specific > > > drivers. > > > > Yes, but so the the webcam modes of the different devices, so for > > the 5 (not sure if that is the right number) dual-cam mode chipsets > > we support there will be 5 drivers, each supporting both the > > webcam and the access to pictures stored in memory of the chipset > > they support. So 5 chipsets -> 5 drivers each supporting 1 chipset, > > and both functions of the single logical device that chipset > > represents. > > > > > Does it really make sense to combine 5 drivers into one? > > > > Right, that is not the plan. The plan is to simply stop having 2 drivers > > for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam > > + 5 webcam, to just 5 drivers. We will also likely be able to share > > code between the code for the 2 functionalities for things like generic > > set / get register functions, initialization, etc. > > Okay, I didn't realize that the different cameras used different webcam > drivers as well as different stillcam drivers. Oh, yes. They are Proprietary devices. And that means what it says. :-) And all different from each other, too. > As far as I can see, there's nothing to stop anybody from adding the > stillcam functionality into the webcam drivers right now. If some > common code can be abstracted out into a shared source file, so much > the better. > > That would solve the problem, right? I think everyone involved believes that it would solve the problem. The question has been all along whether or not there is any other way which would work. Also the question of what, exactly, "belongs" in the kernel and what does not. For, if something has been historically supported in userspace (stillcam support, in this case) and has worked well there, I would think it is kind of too bad to have to move said support into the kernel just because the same hardware requires kernel support for another functionality and the two sides clash. I mean, the kernel is already big enough, no? But the logic that Hans has set forth seems rather compelling. Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
