|Summary:||digikam does not connect to USB camera with libgphoto-2.1.99|
|Product:||[Applications] digikam||Reporter:||Michal Kolodziejczyk <miko>|
|Component:||Import-Gphoto2||Assignee:||Digikam Developers <digikam-bugs-null>|
|Severity:||normal||CC:||ach, anaselli, andresbajotierra, caulier.gilles, debian, erik.andren, gustavo.boiko, hub, ismail, montel|
|Latest Commit:||Version Fixed In:|
The Camera dialog with libgphoto2-2-dev installed
Camera dialog without libgphoto2-2-dev
Description Michal Kolodziejczyk 2006-04-16 22:03:45 UTC
Comment 1 Marcus Meissner 2006-04-17 22:30:04 UTC
does it work with the command line gphoto2? which exact camera is this? C 350d? Canon 350D? You might need to xswitch the camera "PTP" mode.
Comment 2 Michal Kolodziejczyk 2006-04-18 17:43:02 UTC
It is Canon 350D. It works with command-line gphoto2 and with gtkam (which is a GUI). Digikam works again when you downgrade libgphoto2 to 2.1.6. I always have the PTP mode on. In my opinion, digikam is not compatible with libgphoto2 2.1.99, at least when it comes to connecting to the camera with USB.
Comment 3 Kent 2006-04-23 22:26:16 UTC
I've been dabbling with this bug for a few months now with a Canon A620, after having downgraded to 2.1.6 and back and forth. I saw an addition in the gphoto2 docs about the print-usb-usermap being depreciated. With the pre 2.1.99 I have to add a special entry for the camera in the .usermap to use it as a generic PTP camera. After installing 2.1.99 there is no camera listing at all in digikam and thus no functionality. Using the command line gphoto2 and gtkam, the A620 is properly detected. Relevent line from gphoto2 doc: Note (TODO). print-usb-usermap is deprecated as of 184.108.40.206. Use print-camera-list instead. Description of udev rules and HAL setup missing here.
Comment 4 tropikhajma 2006-06-10 15:20:48 UTC
the bug is present in 0.8.2-rc1 in Mandriva Cooker. Downgrading to libgphoto2-2.1.6-8 fixes it for me.
Comment 5 Chris Peikert 2006-06-19 17:20:52 UTC
I see this bug as well, with the new gphoto 2.2.0 release in Debian unstable. I have a "generic PTP camera" set up in digikam, which worked under gphoto 2.1.6 with my PowerShot SD450. Now digikam will not connect to the camera at all to download thumbnails etc, nor will it auto-detect my camera. The camera works fine from the command line with the gphoto2 utility: auto-detection, downloads, etc.
Comment 6 Marcus Meissner 2006-06-19 17:23:27 UTC
libgphoto2 2.2.0 has a new library major version. you need to recompile digikam very likely. you can see this if you try to list all available cameras in digikam.
Comment 7 Chris Peikert 2006-06-19 17:49:07 UTC
I have found a fix to this bug, for Debian at least (no recompile of digikam needed). Install the libgphoto2-2-dev package. Then everything works fine in digikam: auto-detect, connecting to camera, downloading, etc. None of these features work without the -dev package. I cannot tell what is in that package that might make a difference: the only binaries I see are gphoto2-port-config, gphoto2-config, libgphoto2_port.so, and libgphoto2.so. The rest are documentation files, headers, and various .a and .la camera libraries.
Comment 8 Marcus Meissner 2006-06-19 17:52:43 UTC
then its likely the missing .la files for the camera drivers and port drivers. While libtool .la files are usually only used during compilation, for libgphoto2 they are used during runtime too.
Comment 9 Tom Albers 2006-06-20 19:57:33 UTC
Gilles, can't you link against this?
Comment 10 Hubert Figuiere 2006-06-21 19:33:11 UTC
libgphoto2 does not have a new major... It is still .so.2
Comment 11 Achim Bohnet 2006-06-22 00:27:28 UTC
Reproduceable in Kubuntu/Dapper and SuSE 10.1. #6 (Marcus Meisner) #10 (Hubert Fuguiere): also in Kubuntu/Dapper and debian/sid libghoto2 2.1.6 and 2.2.0 (rebuild debian pkg in dapper) have both major version 2: $ l 2.*/usr/lib/libgph*.so.2.* -rw-r--r-- 1 ach ach 101800 2006-05-10 16:31 2.1.6/usr/lib/libgphoto2.so.2.0.3 -rw-r--r-- 1 ach ach 101696 2006-06-20 00:40 2.2/usr/lib/libgphoto2.so.2.1.0 $ objdump -p 2.*/usr/lib/libgph*.so.2.* | grep SONAME SONAME libgphoto2.so.2 SONAME libgphoto2.so.2 Gilles and I tried to rebuild digikam with libgphoto2-2 installed. Still without the 2.2.0's .la files camera list is empty. So it's a runtime, not a build time problem. One difference between 2.1.6 and 2.2.0 is that the camera plugins are /usr/lib/libgphoto2/2.1.6/libgphoto2_<type>.so and /usr/lib/libghoto2/2.2.0/<type>.so respectively. With strace one gets: $ strace digikam --detect-camera 2>&1 | grep /usr/lib/libgphoto2/2.2.0/ open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/adc65", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20", O_RDONLY) = -1 ENOENT (No such file or directory) ... and for gtkkam instead allee(130) ~/tmp $ strace gtkam 2>&1 | grep /usr/lib/libgphoto2/2.2.0/ open("/usr/lib/libgphoto2/2.2.0/adc65.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/adc65.so", O_RDONLY) = 5 open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.la", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libgphoto2/2.2.0/agfa_cl20.so", O_RDONLY) = 5 So while gtkam and digikam use the same libgphoto2 $ ldd /usr/bin/digikam | grep libgphoto libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb6565000) libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb653e000) $ ldd /usr/bin/gtkam | grep libgphoto libgphoto2.so.2 => /usr/lib/libgphoto2.so.2 (0xb7f0c000) libgphoto2_port.so.0 => /usr/lib/libgphoto2_port.so.0 (0xb7f05000) the sequence of files that the apps try to open differ. digikam: .la, then "" gtkam: .la, then .so With the .la files installed digikam tries .la then .so as gtkam does even without the .la files. [the .la files are in kubuntu and debian in the pkg libghoto2-2-dev, that's the reason why the hack/workaround of installing the 2.2.0 devel pkgs fixes a runtime problem] Both use the same ltdl library: $ ldd /usr/bin/digikam /usr/bin/gtkam | grep ltdl libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb62ec000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb761d000) I've no glue yet what goes wrong. My guess is that somehow KDE seems to influence the list of extentions and makes digikam/libghoto2 combo fail to dynamicly load the camera drivers. coolo ping? ;) Achim
Comment 12 Achim Bohnet 2006-06-22 00:30:15 UTC
FWIW: libghoto2 2.2.0 contains a subdir libltdl and the code in their is at least compiled. It's too late now to check if it's used/linked. Nite! Achim
Comment 13 FACORAT Fabrice 2006-08-01 16:30:26 UTC
gphoto2 2.2 is out and this bug is still valid.
Comment 14 Erik Andrén 2006-08-31 14:55:02 UTC
I can confirm this bug on Gentoo, using gphoto2 2.2 and a Canon Digital Ixus 50.
Comment 15 Benjamí Villoslada 2006-10-31 22:02:02 UTC
Debian related bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396249
Comment 16 Benjamí Villoslada 2006-11-05 19:02:31 UTC
Solved today in Debian Sid: digiKam Debian changelog: ------------------------------------------ digikam (1:0.9.0~beta3-3) unstable; urgency=low [ Mark Purcell ] [...] * Re-Add Build-Depends: libgphoto2-2-dev - libgphoto2-2-dev needed (Closes: #396249) [...] -- Debian KDE Extras Team <email@example.com> Sat, 4 Nov 2006 10:12:50 +0000 ------------------------------------------
Comment 17 caulier.gilles 2006-11-06 10:11:07 UTC
Benjamí, Something have been changed in digiKam Debian package to solve this problem ? I want mean something must be changed in current digiKam implementation ? If no, i will close this file... Gilles
Comment 18 Angelo Naselli 2006-11-06 10:26:29 UTC
Gilles, I'm not sure you can close the bug for that. We should check if it is *only* a distro issue or not recall: Re-Add Build-Depends: libgphoto2-2-dev IIRC, mandriva patched digikam as well to have a libgphoto-devel dependency, now I wonder why digikam needs a devel package to run.... My 2 €cents Angelo
Comment 19 Achim Bohnet 2006-11-06 11:22:31 UTC
Hi Angelo, Gilles, Problem is that the new libgphoto plugin names without the 'lib' prefix are not found without the .la files that are in the -devel pkgs. Solutions: move .la files run -devel to -runtime pkgs or find/patch the code so plugins without 'lib' prefix are found without the .la files (see comment #11). Then the dependency on the -devel pkg can be removed. I doubt that it's digikam's fault. IMHO the bug should not be closed but reassigned to the 'lookup plugin' code. (remember gtkam finds the new plugin names without problem, see comment #11) Achim
Comment 20 Marcus Meissner 2006-11-06 11:34:20 UTC
the .la files for the camlibs and ports MUST be in the runtime package. they are NOT development files, but are used during runtime. tell this to the libgphoto2 packager ;)
Comment 21 Benjamí Villoslada 2006-11-06 16:02:06 UTC
Gilles, Only that libgphoto2-2-dev now is needed in Debian [Sid]. Changelog says: * Re-Add Build-Depends: libgphoto2-2-dev - libgphoto2-2-dev needed (Closes: #396249) Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too. Benjamí
Comment 22 Angelo Naselli 2006-11-06 16:39:43 UTC
> Angelo: a friend says that in Ubuntu Edgy he have libgphoto2-2-dev dependency too. That probably means it's a packaging issue...
Comment 23 Thomas Bettler 2007-01-19 00:32:28 UTC
Just a wild guess: (had this troubles too) using udev (but maybe with wrong rules?) 1. check if it works as root -> if yes continue 2. check you got write permissions on your camera $ ls -l /dev/bus/usb/*/* -> have a look at the respective device... You don't? -> set them manually and check if it works now... Solution: you probably want to update your libgphoto package to a recent version or correct the udev rules manually. PS: Need more information: see http://bugs.gentoo.org/show_bug.cgi?id=153471
Comment 24 Mark Purcell 2007-01-19 19:28:39 UTC
From a Debian perspective depending on libgphoto2-2-dev is just a workaround. The real issue is getting the .la files into the runtime package. We are now tracking this issue at http://bugs.debian.org/390703 Mark
Comment 25 Marcus Meissner 2007-01-19 19:38:09 UTC
I wonder why digikam does not use the .so prefix. It is very strange. Using the .la files will fix it, but perhaps someone should check why it does not look for .so. :/
Comment 26 Marcus Meissner 2007-01-19 19:39:50 UTC
i can confirm this behavior on openSUSE 10.2 too.
Comment 27 Mark Purcell 2007-01-19 19:56:23 UTC
Marcus has just informed me that the .la files are not necessary. On Friday 19 January 2007 18:34, Marcus Meissner wrote: > Err, actually the .la files not necessary as I now know. ... Sorry for the confusion. So what is the solution? Does digikam need to be patched to access the .so files and not the .la files, per comment #11 from Achim above?? Mark
Comment 28 Marcus Meissner 2007-01-19 20:07:53 UTC
msp: my mistake... in this case they seem to be as bug workaround for digikam. I have tried finding on why digikam is special here, but so far not much success.
Comment 29 Marcus Meissner 2007-01-19 20:18:28 UTC
Breakpoint 3, 0x00002b99bab7df70 in lt_dlopenext () from /opt/kde3/lib64/libkdecore.so.4 it has its own libltdl compiled in. We use lt_dlopenext ("foo.so"); and it does not handle it correctly => the KDE libltdl version is too old for the stuff libgphoto2 does with it :(
Comment 30 Ismail Donmez 2007-01-19 20:32:53 UTC
So we need to upgrade kdelibs' internal libltdl. Is that safe?
Comment 31 Marcus Meissner 2007-01-19 20:42:20 UTC
It would help more to have LTDL_SHLIB_EXT supported in this libltdl copy. if LTDL_SHLIB_EXT is set (to ".so" on Linux), the code would work.
Comment 32 Ismail Donmez 2007-01-19 21:32:09 UTC
so something like CFLAGS=-DLTDL_SHLIB_EXT=".so" ./configure should work for kdelibs?
Comment 33 Norbert Pfistner 2007-01-27 14:55:02 UTC
The bug seems to be still alive with digikam 2:0.8.2-3 libgphoto2-2 2.2.1-12 libgphoto2-2-dev 2.2.1-12 on debian testing using our canon EOS 350D in PTP mode (non-PTP mode doesn't work either, but PTP-mode worked fine before the upgrade).
Comment 34 caulier.gilles 2007-02-05 09:08:41 UTC
Marcus, Is the problem with digiKam Makefile.am and libgphoto2 ? If Kamera tool work fine, well take a look of the current Makefile.am relevant here: http://websvn.kde.org/branches/KDE/3.5/kdegraphics/kamera/kioslave/Makefile.am?rev=466285&view=auto ... and compare with digiKam Makefile.am: ==> for the camera gui : http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/cameragui/Makefile.am?rev=610979&view=auto Look like it's different, especially about LDFLAGS stuff and $(GPHOTO2_LIBS) witch is not present in cameragui Makefile.am. This can be the problem ? Gilles Caulier
Comment 35 verduin 2007-02-08 21:25:54 UTC
I confirm this with FC-6 and Olympus 3030 hardware today, also gphoto2 result. My FC-6 is a fresh install with all updates per two days ago. See comment #33 / all revs are later than those listed. Add digiKam is R0.9.0(Using KDE 3.5.5-...fc6), gphoto2 is R2.3.1 Analysis: With digiKam -- The camera connect request First opens a camera window - then opens a fatal error window. "Failed to connect to the camera. ..." With gphoto2 --list ports Two ports found prior to camera - ptpip:, and usb: Two more found after camera "ON" - usb:001,004, usb:002,003 With gphoto --auto-detect Olympus C-2100UZ found (wrong!? Olympus-3030Z also exists in .fdi) May not matter? from inspection of .fdi, 2100UZ and 3030Z seem similar... Forcing use of C-3030Z yields same result. Two ports listed - usb:, usb:001,005 I suspect first (without x,y) entry may be incorrect...? NOTE! from /proc/bus/usb directory listing usb:001,005 does exist with OK UID & permissions usb:002,003 does exist with only root perms usb:001,004 does not exist (see --list ports above) With gphoto2 -a On the surface the output seems normal and correct With gphoto2 ... -l Fatal error: "Could not release interface 0 (Invalid argument)." I have debug trace available -- if useful eamil me for attachment... Error began with this: "...gphoto2-port(0): Could not query kernel driver of device" NOTE: My FC-5 had lesser problem - only root could use USB camera interface. Today the issue is a more total failure, probably with HAL and setting USB drivers. I find nothing to adjust nor a workaround. Advise if I can can further test.
Comment 36 Norbert Pfistner 2007-02-14 16:08:59 UTC
After fiddling around with gphoto2 I finally got my Canon EOS 350D working (again): 1) I had to add users to group plugdev (group camera is not used any more). Well so far simply some permissions. 2) I had to use CANON EOS 350D without(!) PTP mode despite the camera itself is still set to PTP connection (PC connection does not work!). Funny, isn't it? So at least my bugreport should better be posted to the gphoto dev. Just for information: digikam 2:0.8.2-4 libgphoto2-2 2.2.1-12 libgphoto2-2-dev 2.2.1-12 gphoto2 2.2.0-3 on debian testing Norbert Pfistner
Comment 37 Mark Purcell 2007-06-19 18:43:14 UTC
Ubuntu are claiming they have been able to fix this issue due to the way Kubuntu KDE finds the gphoto libs.. I can confirm this issue is not fixed in Debian with KDE 3.5.7 and digikam 0.9.2 final. Thus Debian is continuing to ship with a dependency on libgphoto2-2-dev. I have asked the Ubuntu guys, what changes they made to kdelibs... Mark
Comment 38 Mark Purcell 2007-07-08 22:57:05 UTC
Created attachment 21091 [details] The Camera dialog with libgphoto2-2-dev installed
Comment 39 Mark Purcell 2007-07-08 22:57:42 UTC
Created attachment 21092 [details] Camera dialog without libgphoto2-2-dev
Comment 40 Daniel Hahler 2007-10-04 03:29:59 UTC
The Ubuntu bug report is at https://launchpad.net/bugs/145239
Comment 41 Mark Purcell 2007-11-13 08:03:56 UTC
Thanks to pusling this seems to fix: --- kdelibs-3.5.8.dfsg.1.orig/libltdl/ltdl.c +++ kdelibs-3.5.8.dfsg.1/libltdl/ltdl.c @@ -184,6 +184,7 @@ #define LT_DLSTRERROR(name) lt_dlerror_strings[LT_CONC(LT_ERROR_,name)] static const char objdir = LTDL_OBJDIR; +#define LTDL_SHLIB_EXT ".so" #ifdef LTDL_SHLIB_EXT static const char shlib_ext = LTDL_SHLIB_EXT; #endif
Comment 42 caulier.gilles 2007-11-13 08:11:35 UTC
Mark, What's this patch. Where it is applied exactly ??? Sound like a file from KDE core library... Right ??? Laurent, Please, please, please take a look and fix it in svn... (:=))) Gilles
Comment 43 Mark Purcell 2007-11-15 08:47:32 UTC
This is what pusling has done with Debian kdelibs: kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low * Add a patch to allow to dlopen .so files and not only .la files. Now kamera, digikam and others doesn't need to depend on -dev packages. -- Sune Vuorela <firstname.lastname@example.org> Mon, 12 Nov 2007 13:00:41 +0100
Comment 44 caulier.gilles 2007-11-15 09:39:11 UTC
Mark, Thanks a lots for this patch. This is what i suspected but never find it... So, the problem come from KDELibs. This one need to be patched in svn to close this file definitively... Angelo, For Mandriva package, i recommend you to patch kdelibs temporally, as Debian team... Gilles Caulier
Comment 45 caulier.gilles 2007-11-15 09:46:31 UTC
To KDE-Libs team : I re-affect this file to your part. The solution to solve it is described by Debian team in #41 and #43. Patch is really simple and easy to test. Please take a look. Thanks in advance... Gilles Caulier
Comment 46 Sune Vuorela 2007-11-16 10:35:04 UTC
To add a bit more details. It seems that gphoto dlopens its plugins (on debian placed in /usr/lib/libgphoto2/2.4.0/) gphoto uses normally the system libltdl to do the dlopens. But in this case ... kdelibs ships its own embedded libltdl - and in kde applications kdelibs gets loaded first - and then "wins" over the systems other libraries when looking for some functions. The real fix would be to use the system libltdl instead of embedding a copy in kdelibs. (it was comments 31 and 32 that lead me in the right direction - but I just couldn't find the proper way to escape the ".so" if I wanted a -DLTDL_SHLIB_EXT=".so" passed in. That should do the trick as well)
Comment 47 Sune Vuorela 2007-11-16 13:10:14 UTC
I just made kdelibs build against external libltdl instead of the embedded one. I wonder how much breakage to expect from this. Any clues what to test ? The usage of lt_dlopen_flag in kinit.cpp and klibloader.cpp needed to go away to make it build. I have no clue wether it breaks anything or not.
Comment 48 Sune Vuorela 2007-11-16 23:26:33 UTC
oh well.. it just broke kded and maybe a couple of other things. Using external libltdl is not recommended right now at least. /Sune
Comment 49 Dario Andres 2009-05-01 20:27:10 UTC
Any news on this with recent versions ?
Comment 50 Mark Purcell 2009-05-02 02:45:54 UTC
We fixed this is Debian with a patch to kdelibs.. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416123 kdelibs (4:3.5.8.dfsg.1-4) unstable; urgency=low * Add a patch to allow to dlopen .so files and not only .la files. Now kamera, digikam and others doesn't need to depend on -dev packages. -- Sune Vuorela <email@example.com> Mon, 12 Nov 2007 13:00:41 +010 All looks good in KDE4 too. Mark
Comment 51 Michal Kolodziejczyk 2009-05-04 10:47:14 UTC
Since I am using recent version of KDE4 and digikam (on archlinux - the package contains no patches), things work for me, and I am ready to close this bug report. Should I close it, or should it still be open?
Comment 52 caulier.gilles 2009-05-04 22:14:01 UTC
It's fine for me to close this file. Any objections from others peoples ? Gilles Caulier
Comment 53 Johannes Wienke 2010-02-17 17:03:47 UTC
No objections since more than half a year. Closing this now.