Re: USB mini-summit at LinuxCon Vancouver
From: Theodore Kilgore
Date: Wed Aug 10 2011 - 10:59:21 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/