On Thu, 4 Aug 2011, Jean-Francois Moine wrote: > On Thu, 04 Aug 2011 09:40:18 -0300 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > > > > What we need for this is a simple API (new v4l ioctl's I guess) for the > > > stillcam mode of these dual mode cameras (stillcam + webcam). So that the > > > webcam drivers can grow code to also allow access to the stored pictures, > > > which were taken in standalone (iow not connected to usb) stillcam mode. > > > > > > This API does not need to be terribly complex. AFAIK all of the currently > > > supported dual cam cameras don't have filenames only picture numbers, > > > so the API could consist of a simple, get highest picture nr, is picture > > > X present (some slots may contain deleted pictures), get picture X, > > > delete picture X, delete all API. > > > > That sounds to work. I would map it on a way close to the controls API > > (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to expand > > it in the future, if we start to see webcams with file names or other things > > like that. > > I did not follow all the thread, but I was wondering about an other > solution: what about offering both USB mass storage and webcam accesses? > > When a dual-mode webcam is plugged in, the driver creates two devices, > the video device /dev/videox and the volume /dev/sdx. When the webcam is > opened, the volume cannot be mounted. When the volume is mounted, the > webcam cannot be opened. There is no need for a specific API. As Mauro > said: > > > For those, we may eventually need some sort of locking between > > the USB storage and V4L. > > That's all. By where am I wrong? Jean-Francois, This idea seems to me basically on track. There is only one small problem with it, in the details: As far as I know, /dev/sdx signifies a device which is accessible by something like the USB mass storage protocols, at the very least. So, if that fits the camera, fine. But most of the cameras in question are Class Proprietary. Thus, not in any way standard mass storage devices. Then it is probably better not to call the new device by that name unless that name really fits. Probably, it would be better to have /dev/cam or /dev/stillcam, or something like that. Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
