Hi all,
On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 20:20, Theodore Kilgore escreveu:
<snip snip>
Yes, that kind of thing is an obvious problem. Actually, though, it may be
that this had just better not happen. For some of the hardware that I know
of, it could be a real problem no matter what approach would be taken. For
example, certain specific dual-mode cameras will delete all data stored on
the camera if the camera is fired up in webcam mode. To drop Gphoto
suddenly in order to do the videoconf call would, on such cameras, result
in the automatic deletion of all photos on the camera even if those photos
had not yet been downloaded. Presumably, one would not want to do that.
So, in other words, the Kernel driver should return -EBUSY if on such
cameras, if there are photos stored on them, and someone tries to stream.
Agreed.
IMO, the right solution is to work on a proper snapshot mode, in kernelspace,
and moving the drivers that have already a kernelspace out of Gphoto.
Well, the problem with that is, a still camera and a webcam are entirely
different beasts. Still photos stored in the memory of an external device,
waiting to be downloaded, are not snapshots. Thus, access to those still
photos is not access to snapshots. Things are not that simple.
Yes, stored photos require a different API, as Hans pointed. I think that some
cameras
just export them as a USB storage.
Erm, that is not what I tried to say, or do you mean another
Hans?
<snip snip>
If I understood you well, there are 4 possible ways:
1) UVC + USB mass storage;
2) UVC + Vendor Class mass storage;
3) Vendor Class video + USB mass storage;
4) Vendor Class video + Vendor Class mass storage.
Actually the cameras Theodore and I are talking about here all
fall into category 4. I expect devices which do any of 1-3 to
properly use different interfaces for this, actually the different
class specifications mandate that they use different interfaces
for this.
This sounds to be a good theme for the Workshop, or even to KS/2011.
Agreed, although we don't need to talk about this for very long, the solution
is basically:
1) Define a still image retrieval API for v4l2 devices (there is only 1
interface for both functions on these devices, so only 1 driver, and to
me it makes sense to extend the existing drivers to also do still image
retrieval).
2) Modify existing kernel v4l2 drivers to provide this API
3) Write a new libgphoto driver which talks this interface (only need to
do one driver since all dual mode cams will export the same API).
1) is something to discuss at the workshop.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
