(re-adding all from the original CC-list, please, don't drop anyone)
On Thu, 4 Aug 2011, Jean-Francois Moine wrote:
On Thu, 04 Aug 2011 09:40:18 -0300 Mauro Carvalho Chehab mchehab@redhat.com 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?
That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? "Just" learn to share a device between several existing drivers.
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
Em 04-08-2011 16:02, Guennadi Liakhovetski escreveu:
(re-adding all from the original CC-list, please, don't drop anyone)
On Thu, 4 Aug 2011, Jean-Francois Moine wrote:
On Thu, 04 Aug 2011 09:40:18 -0300 Mauro Carvalho Chehab mchehab@redhat.com 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?
Because not all devices export an USB mas storage.
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?
That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? "Just" learn to share a device between several existing drivers.
For those that can export data into some fs-like way, this may be the better way. It seems that gvfs does something like that. I've no idea how easy or difficult would be to write Kernel driver for it.
Thanks Guennadi
Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? "Just" learn to share a device between several existing drivers.
For those that can export data into some fs-like way, this may be the better way. It seems that gvfs does something like that. I've no idea how easy or difficult would be to write Kernel driver for it.
As I understand it gvfs uses libgphoto2 and fuse and it is the interface libghoto2 that is the problem. libgphoto2 contains lots of the same sort of code to handle strange data formats from the camera as libv4l so I don't think we want to be moving that code back into the kernel.(The old out of kernel driver for sq905 before Theodore and I rewrote it contained code to do Bayer decoding and gamma correction that was copied from libgphoto2).
Regards
Adam Baker
Em 04-08-2011 18:38, Adam Baker escreveu:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? "Just" learn to share a device between several existing drivers.
For those that can export data into some fs-like way, this may be the better way. It seems that gvfs does something like that. I've no idea how easy or difficult would be to write Kernel driver for it.
As I understand it gvfs uses libgphoto2 and fuse and it is the interface libghoto2 that is the problem. libgphoto2 contains lots of the same sort of code to handle strange data formats from the camera as libv4l so I don't think we want to be moving that code back into the kernel.(The old out of kernel driver for sq905 before Theodore and I rewrote it contained code to do Bayer decoding and gamma correction that was copied from libgphoto2).
I don't think we should move the entire libgphoto2 to kernel. For sure, format conversions don't belong to Kernelspace. We just need to move the file handling (e. g. PTP/MTP) to a kernel driver. Something might be needed for libgphoto2 to know what is the format of the images inside the filesystem, but this could be just mapped as a file extension.
Regards
Adam Baker
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? "Just" learn to share a device between several existing drivers.
For those that can export data into some fs-like way, this may be the better way. It seems that gvfs does something like that. I've no idea how easy or difficult would be to write Kernel driver for it.
As I understand it gvfs uses libgphoto2 and fuse and it is the interface libghoto2 that is the problem.
This is correct. Except that the problem is not in libgphoto2 per se, but is at an even lower level. It could be said that the problem is in libusb, because libghoto2 uses libusb. So maybe the solution is to fix up libusb. Or, as I have come recently to think, maybe not. In any event, neither use nor avoidance of gvfs has much of anything to do with the problem at hand. But the problem exists with it or without it.
libgphoto2 contains lots of the same sort of
code to handle strange data formats from the camera as libv4l so I don't think we want to be moving that code back into the kernel.(The old out of kernel driver for sq905 before Theodore and I rewrote it contained code to do Bayer decoding and gamma correction that was copied from libgphoto2).
This is all very much true. Moreover, I do not think that anyone has the idea to put any of that kind of code back into the kernel.
But, just in case that anyone is thinking of possible "overlap" between what is done in libv4l and libgphoto2, someone should point out that things like Bayer demosaicing and gamma correction are not necessarily done the same way in the two libraries. Why is that? Well, it is true because one of the libraries supports streaming and the other one supports still cameras. Thus, the Bayer demosaicing functions in libv4l are optimized for speed, which will directly affect the frames per second rate. The Bayer demosaicing functions in libusb are intended to process image data from still cameras. For a still camera, frame rate is irrelevant and meaningless. Therefore the priority is, or ought to be, to get the best possible image out of the downloaded image data.
Theodore Kilgore
-
Adam Baker -
Guennadi Liakhovetski -
Mauro Carvalho Chehab -
Theodore Kilgore