Date:	Thu, 11 Aug 2011 10:14:33 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Theodore Kilgore <kilgota@...ach.math.auburn.edu>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg KH <greg@...ah.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	linux-usb@...r.kernel.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, libusb-devel@...ts.sourceforge.net,
	Alexander Graf <agraf@...e.de>,
	Gerd Hoffmann <kraxel@...hat.com>, hector@...cansoft.com,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	pbonzini@...hat.com, Anthony Liguori <aliguori@...ibm.com>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Oliver Neukum <oliver@...kum.org>, Felipe Balbi <balbi@...com>,
	Clemens Ladisch <clemens@...isch.de>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Adam Baker <linux@...er-net.org.uk>
Subject: Re: USB mini-summit at LinuxCon Vancouver

Hi,

On 08/10/2011 06:09 PM, Alan Stern wrote:
> 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?
>

First of all thanks for the constructive input!

When you say: "device-sharing protocol", do you mean 2 drivers been
attached, but only 1 being active. Or just some additional glue to make
hand-over between them work better?

I've 2 concerns with this approach:
1) Assuming we are going for the just make hand over work better solution
we will still have the whole disappear / reappear act of the /dev/video#
node, which I don't like at all.

If for example skype gets started it will say the user has no camera. If it
were to say the device is busy, the user just might make a link to some
application using the device in stillcam mode still being open.

2) The whole notion of the device being in use is rather vague when it comes
to the userspace parts of this. Simply leaving say F-Spot running, or having
a gvfs libgphoto share mounted, should not lead to not being able to use the
device in webcam mode. But currently it will.

Fixing all users of libgphoto2 wrt this is unlikely to happen, and even if
we do that now, more broken ones will likely come along later. I estimate
98% of all cameras are not dual mode cameras, so the average stillcam
application developer will not test for this.

That leaves us with fixing the busy notion inside libgphoto2, iow, release
the device as soon as an operation has completed. This will be quite slow,
since both drivers don't know anything about each other, they will just
know there is some $random_other_driver. So they need to assume the
device state is unclean and re-init the device from scratch each time.

Where as if we have both functions in one driver, that can remember the
actual device state and only make changes if needed, so downloading +
deleting 10 photos will lead to setting it to stillcam mode once, rather
then 20 times.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists