Subject: Fwd: Problem with 2.4.0 version on ubuntu - msg#00021

Previous Message by Date: click to view message preview

Re: Jeilin cameras, and some policy questions.

On Tue, 11 Sep 2007, Hans Ulrich Niedermann wrote: > kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote: >> >> On Tue, 4 Sep 2007, Hans Ulrich Niedermann wrote: >> >>> kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote: >> >> [...] >>> I see your directory is called camlibs/jl2005c and it contains source >>> for the jl2005c.so camlib. In case you want to add another camlib >>> jl2005b.so later which shares some code, I suggest you rename the >>> directory to camlibs/jeilin and build both jl2005b.so and jl2005c.so >>> from sources there. > >> While trying to figure out some more about the jl2005c camera, which seems >> to be a difficult case, I have started to work on the jl2005a. I wonder if >> you might have some suggestions about how to put this idea of a single >> jeilin camlib in practice, given that the usual model I have been >> following (which I understand is the standard way) is to do >> library.c, with standard functions in it (but with calls to >> functions with names which are camera-specific) >> camera.c, with camera-specific stuff in it and function names >> which are camera-specific, too >> camera.h, containing what it obviously needs to contain (header >> file for camera-specific functions, sets up things in the PrivateLibrary, >> that kind of thing) > > I would not have thought about creating a single camlib - just about > grouping the source code for two camlibs with similarities in a way that > makes it easier to maintain. > > In case of larger similarities, I would have imagined a common library.c > and low-level-protocol.c, and camera-specific jl2005a.c and jl2005c.c. > The library.c would then call jeilin_FOO(), and both jl2005a.c and > jl2005c.c would implement the jeilin_* interface defined in jeilin.h. > > In case of less similarities, one library.c and camera.c each, and > perhaps a common low-level-protocol.c. These can be placed into > different subdirectories. > > In case of totally separate camlibs, I would have just placed them into > subdirectories camlibs/jeilin/${CAMERA}/ (similar to camlibs/kodak/). > >> I have looked at camlibs/sipix for an example, and this standard scheme is >> not followed there. I am not sure that it is good to create one humongous >> file called jl2005c.c with everything in it, and then another humongous >> file called jl2005a.c with everything in it, just in order to shoehorn >> cameras into a subdirectory called camlibs/jeilin. It does appear to me, >> though, that this is more or less the way that things have been done in >> camlibs/sipix. So if camlibs/sipix is not the good model to follow here, >> then what is? > > > I can think of these "good" ways to build two camlibs jl2005a.so and > jl2005c.so: > > A) Completely separate dirs. > camlibs/jl2005a/library.c > camlibs/jl2005a/jl2005a.c > camlibs/jl2005c/library.c > camlibs/jl2005c/jl2005c.c > > B) Group dirs by manufacturer. > camlibs/jeilin/jl2005a/library.c > camlibs/jeilin/jl2005a/jl2005a.c > camlibs/jeilin/jl2005c/library.c > camlibs/jeilin/jl2005c/jl2005c.c > > C) Have some common source files in the same dir. > camlibs/jeilin/library.c (used for both camlibs) > camlibs/jeilin/lowprot.c (low level proto used for both camlibs) > camlibs/jeilin/jl2005a.c (jl2005a specific stuff) > camlibs/jeilin/jl2005c.c (jl2005c specific stuff) > > D) Have some common source files in separate dir in same tree. > camlibs/jeilin/jl2005a/library.c > camlibs/jeilin/jl2005a/jl2005a.c > camlibs/jeilin/jl2005c/library.c > camlibs/jeilin/jl2005c/jl2005c.c > camlibs/jeilin/common/low-level.c (common low level code) > > So far, we are using both schemes A) and B) somewhere. > > You have started using A), and if you like that, that is fine with me. > > If C) or D) seem better for you, go for it. > > And if you start out using A) and see that you could use some common > file, you can just use that using A) as well. The _SOURCES will then > just contain both jl2005a/foo.c and jl2005c/bar.c files. In this case, > however, we'd better rename the files a little later. > > In the end, the most important thing is that the people actually working > on the camlib code are comfortable with it - and that is you, not me :-) > I'll happily assist you with setting up the basic layout, though. > >> In other words, there is hardly any similarity at all between jl2005c and >> jl2005a, except for the lengths of the commands (2 bytes) and responses (1 >> byte) and the fact that both cameras have two pairs of bulk endpoints and >> use one pair for commands and the other for moving data. > > Ok, that means potentially sharing a low-level.c might make sense, but > certainly not more. Actually not, it seems to me, since the command sequence is entirely different. > >> I certainly do agree in principle about combining things when they ought >> to be combined, and I think it would be very nice to combine these if it >> is reasonably possible to do so and does not violate logical structure and >> design principles. In this case I do not see how to go about it, as I >> said. If you have some suggestions about this, I would be very glad to >> know of them, before I get too far into doing things with this other >> camera. > > If you as the person the most familiar with the code don't see any > reasonable way to combine the code, then don't. > > We may still want to place the respective subdirs for the two camlibs > under one common directory (see B). > Hans, Thanks for the analysis. It does seem to me that on this particular occasion the logical choice would be either A or B. Obviously, I could do it either way, in the long run. Right now the job is actually to get the JL2005A camera to work (which it appears at this time will be feasible) and the JL2005C looks like a bit longer-range project. So right now I just try to come up with some code which makes the camera do its thing, and then we see what can be done. In sum, though, I have no problem at all with doing things the way you propose in B, C, or D as a longer-range goal but I would think that in various situations it would be most logical to do what comes out to be the simplest. Another example of this kind of problem occurs in the case of SQ cameras. We have the old sq905 cameras, of which there will not be any more because the chip in them is now discontinued. With the newer chip(s) from SQ, there was a change in the protocols, which, though similar, appear to me to be too difficult to reconcile with the old ones. But then we have camlibs/digigr8 which in fact already supports cameras with three different product ids. Then there is the old library called camlibs/iclick. The communication protocols for that one are just about identical to the ones for the cameras in camlibs/digigr8, and I suspect that there is some similarity, too, in the decompression algorithm used there. I really do think it would be appropriate to combine those libraries and get rid of camlibs/iclick. The problem is, the owner of the only iClick camera that I know of has ceased communication. So the only thing I can do about the matter is precisely nothing, unless and until someone comes forth with another one of those cameras. Theodore Kilgore ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Next Message by Date: click to view message preview

Re: Jeilin cameras, and some policy questions.

> I have looked at camlibs/sipix for an example, and this standard scheme is > not followed there. I am not sure that it is good to create one humongous > file called jl2005c.c with everything in it, and then another humongous > file called jl2005a.c with everything in it, just in order to shoehorn > cameras into a subdirectory called camlibs/jeilin. It does appear to me, > though, that this is more or less the way that things have been done in > camlibs/sipix. So if camlibs/sipix is not the good model to follow here, > then what is? It very much depends on how large in codesize your camera library is to be. If all files together are less than say 1000 lines than you can safely put it into just 1 file. If you want a better separation, you can split it of course. The sipix/ cameras have completely different protocols and are just in the same directory for their names. Ciao, Marcus ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Previous Message by Thread: click to view message preview

Updating the API for the csharp binding... advice required

Hi,I've joined up recently to help extend the Mtp support in Banshee. So as part of that, i've taken on some duties with regards to libgphoto2-sharp, namely i'm going to help maintain it for a while and help extend it's features (when needed). At the moment, the binding seems pretty much feature complete in that it wraps every C function that libghoto2 exposes. So, my major gripe is that there is no proper API in the csharp binding. It's a direct copy of the C api, which makes it a hellofalot more awkward to use than it should. For example, connecting to a specific camera using the csharp binding as it stands now takes about 50 LOC and is non trivial. It took me about 15-20 mins to figure out exactly what i was supposed to do to connect to a specific device. In a 'proper' API, this would be a single method call. This is what i'm aiming towards. I want the user to be able to do this:Camera[] cameras = Controller.GetConnectedCameras();foreach(Camera cam in cameras)     cam.Connect();I've already emailed trickv, the current maintainer of the binding, with a bit of information on this and a few questions. So i'm pinging this list to see if there's anyone here who'd be willing to check out the new API once it's written up on paper and critique it. Also, the plan is to (eventually) remove the old API. However, both API's can easily coexist with each other. The plan is to first, develop and implement the new api, secondly mark the old API as obsolete so that people migrate over to the new API and finally make the old api non-public to force people to use the new API. The only step along the way which will make the binding non-API or non-ABI compatible would be the last step, where we hide the old API. So, if anyone is interested in giving a hand in any way, shape or form, send me an email and i'll make sure you're CC'ed on all communications and you can comment at will.Thanks,Alan. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Gphoto-devel mailing list Gphoto-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/gphoto-devel

Next Message by Thread: click to view message preview

Re: Fwd: Problem with 2.4.0 version on ubuntu

On 9/11/07, Luka Renko <lure@xxxxxxxxxx> wrote: > > I am trying to package libgphoto2 2.4.0 version for upcoming Ubuntu gutsy > release. It looks like that new version works on initial operation to the > camera, but may fail when the same command is requested the second > time. > > I have created two log files with my Canon PowerShot G3 which is connected via > USB (UMS). The first command succeeded, while the second (run immediatelly > after first) failed with this error: > > Detected a 'Canon:PowerShot G3 (normal mode)'. > *** Error (-114: 'OS error in camera communication') *** I had a problem with my PowerShot A520. It turned out that there was a usb_reset() call added for Canon USB cameras, but it causes some to not work. Here's a commit on the 2.4 branch that "fixed" things for me. http://gphoto.svn.sourceforge.net/viewvc/gphoto/branches/libgphoto2-2_4/libgphoto2/libgphoto2_port/usb/libusb.c?r1=10611&r2=10610&view=patch&pathrev=10611 I say "fixed" because the camera still doesn't connect correctly the first time, but it rarely worked correctly with the usb_reset(). -- Dan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/