[gphoto-devel] Report on Vivicam 3350B and patch intended to support it

[<ki...@ba...>]

First, the question of the non-standard request types, and the patch which 
was intended to support them:

The patch works, in the sense that it does indeed enable communication 
with the camera. However, it causes serious timing problems and therefore 
I withdraw it. The apparent problem is that there are just too many hoops 
to jump through, if the request type is defined in the camera library. The 
suggestion made by Michel Xhaard during the discussion of the problem does 
work and does not cause timing problems. Functionally, the difference is 
that the request-types are hard-wired in libgphoto2_port/usb/libusb.c 
instead of being supplied only in the camlib. I have done something like 
that on my test machine, and there is absolutely no problem talking to the 
camera.

There are however several problems with the camera.

1. It is not always clear what the size of the data in a given photo is 
supposed to be. I found a certain place in the download sequence where 
the size is clearly given, and sometimes the camera honors that. But it 
seems to depend on the day of the week whether a photo is actually that 
size or not. Actually, to be serious, it seems to depend on the lighting 
conditions and/or the amount of detail in the photo. It seems that if the 
photo is not taken in broad daylight then the camera "falls back" on a 
fixed sixe for the photo, which can be significantly less than the nominal 
size. Very unfortunately, I am so far unable to find any previous 
indication in the logs that this is about to happen. Consequently, I can 
get one photo out of the camera if I have a log which will tell me how big 
the data for the photo is, and that's about it.

2. It is not obvious what the data format is and how to decompress it. I 
got one photo out and saved the binary dump of the data as a "raw" file. I 
will be glad to share that with wnyone who might be curious. Michel is 
already looking at it, and after several days he did not get back to me. 
So I suspect it is not easy for him and the format is something weird.

3. The camera uses a "reset pipe" or "reset endpoint" operation every time 
it is going to do a data download. I am not sure of the reason (if there 
is any actual reason) why it needs this, or what precisely the "reset" is 
supposed to do, as opposed to, say, a clear_halt or a close and open. But 
there is a reset listed in /usr/include/usb.h and I have built the support 
for it in libgphoto2_port just in case it really is needed. Whatever it is 
doing, it does it without complaints, in my testing.

4. What I describe here is perhaps related to (3). In one of my 
experiments with the camera, I had two photos on it for which the size was 
accurately described. The second was larger than the first. The photo 
download function reads the size of the photo to be downloaded, by number, 
and is supposed to act on that information. It did. But the camera had a 
different opinion. It only sent the amount of data for the second photo, 
which was the size given for the first, and failed to send the rest of the 
data for the second photo. If I can duplicate this situation, then perhaps 
the resetep function will help. Seems that the camera was stuck, or 
something.

5. Another thing which might be causing additional problems with this 
camera is that there seems to be an insistence to look for EXIF data. And 
when there is no EXIF data to be found in the photo, then (in spite of 
anything I know how to do, to stop it) there is something hidden deep 
within the bowels of gphoto2-libgphoto2 which absolutely insists that the 
photo data (for the same photo) should be downloaded again in order to 
look for the EXIF data. As this also is a question which relates to some 
of my other camera driver libraries, is there any way to stop this? That 
is, aside from compiling the whole of libgphoto2 without EXIF support, 
which would clearly impair the support for some other cameras? 
I am not sure, but in the case of this camera it could also be a cause of 
the camera's confusion about the size of the second photo, because the 
EXIF-searching routine forces the command to be sent to the camera, which 
reads the size of the photo just downloaded, after that size was just read 
prior to downloading it. And then after the camera is (I suspect) 
thoroughly confused by this and very likely is jammed by being presented 
with an out-of-sequence command, one tries to download the next photo.

Well, this describes the current situation with this camera, which was the 
purpose of this report. I would especially appreciate to know whether 
anyone sees actual need and utility for a resetep function. I suspect that 
the answer to this question has got something to do with the fact that 
currently there is no such resetep function existing in libgphoto2_port, 
so either it has been considered superfluous or has been considered 
irrelevant. I also would appreciate it very much if there is some way to 
turn off completely the EXIF stuff for a particular camera, and not for 
all the rest of them.

Theodore Kilgore