On Wed, 10 Aug 2011, Theodore Kilgore wrote: > > 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. The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? Alan Stern -- 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
