| Summary: | Import from camera doesn't find path | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jan van Bekkum <Jan.vanBekkum> |
| Component: | Import-WIA | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | alain.pouchard1410, caulier.gilles, jp.boucher1, jskarvad, marcus, matthias.jorns, metzpinguin, testdroid, wpvking |
| Priority: | NOR | ||
| Version: | 7.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 388137 | ||
| Attachments: |
Managed camera devices (attachment 1)
Camera settings screen (image 2) Smartphone visible Smartphone not visible Cannot connect attachment-890420-0.html |
||
|
Description
Jan van Bekkum
2018-09-02 17:12:38 UTC
Created attachment 114748 [details]
Camera settings screen (image 2)
See previous comment
USB is here for a GPhoto2 device, but what in Windows is not currently supported. You have to choose from the list the "Directory Browse" camera (port is then NONE) and select the appropriate path. See the help text in the dialogue in the first section is a link to this camera. Maik I tried with a path (N:\Pictures Margriet\2007 05 06)only (not selecting USB or any of the other options, but the result was the same. And again when I selected Edit all settings were gone. Maik, We are under Windows here... There is no libgphoto2 support for the moment. We have a report to include libgphoto2 in Windows build process, as recently somebody add a first try to compile this library under Windows. So my Q is : why this option still available in this case. Gilles I understand, thanks. Good news : the last stable libgphoto2 2.5.18 cross compile file with MXE for windows target. So i will include the library in next installer and recompile whole digiKam with gphoto2 support. Gilles Caulier Git commit e46413392f880991744ba3e88a67a24afb8484a2 by Gilles Caulier. Committed on 03/09/2018 at 15:36. Pushed by cgilles into branch 'master'. update bundle to last stable libgphoto2 2.5.19 enable libgphoto2 compilation under MXE for Windows Related: bug 379970, bug 398061 M +1 -0 project/bundles/mxe/01-build-mxe.sh https://commits.kde.org/digikam/e46413392f880991744ba3e88a67a24afb8484a2 digiKam 7.0.0 stable release is now published and now available as FlatPak: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier I did the following tests: NOKIA SMARTPHONE Steps: 1. Connect Nokia 8.1 smartphone via USB to Windows 10 PC. In Windows explorer the smartphone is visible (image 1) 2. In Digikam select Import>Cameras>Add camera manually. In the Mount Path list the smartphone os NOT visible (image 2) NAS-DRIVE Steps: 1 In Digikam select Import>Cameras>Add camera manually. Select one folder from the NAS in the mount path list. 2. Select Import>Cameras><Just added NAS folder>. A "failed to connect" error is shown (image 3). Created attachment 130873 [details]
Smartphone visible
Created attachment 130874 [details]
Smartphone not visible
Created attachment 130875 [details]
Cannot connect
Git commit c3077451a517fb160e0e25a9991a279948610500 by Gilles Caulier. Committed on 08/01/2021 at 15:58. Pushed by cgilles into branch 'master'. Add new dialog with all devices detected by KF5::Solid hardware interface. This will allow to investiguate about missing device detections, or wrong device types assignments in Solid interface, especially under Windows and macOS. Related: bug 393416, bug 379970, bug 381729, bug 412466, bug 431107 M +2 -1 core/app/main/digikamui5.rc M +2 -0 core/libs/dialogs/CMakeLists.txt A +327 -0 core/libs/dialogs/solidhardwaredlg.cpp [License: GPL (v2+)] A +57 -0 core/libs/dialogs/solidhardwaredlg.h [License: GPL (v2+)] M +11 -0 core/libs/widgets/mainview/dxmlguiwindow.cpp M +1 -0 core/libs/widgets/mainview/dxmlguiwindow.h M +2 -1 core/showfoto/main/showfotoui5.rc M +12 -0 core/tests/miscs/CMakeLists.txt A +41 -0 core/tests/miscs/solidhardware.cpp [License: GPL (v2+)] M +2 -1 core/utilities/imageeditor/main/imageeditorui5.rc M +3 -1 core/utilities/import/main/importui5.rc M +2 -1 core/utilities/lighttable/lighttablewindowui5.rc M +2 -1 core/utilities/queuemanager/main/queuemgrwindowui5.rc https://invent.kde.org/graphics/digikam/commit/c3077451a517fb160e0e25a9991a279948610500 Git commit 1d69260946da53b92067105224468723482e2f8c by Gilles Caulier. Committed on 09/01/2021 at 19:20. Pushed by cgilles into branch 'master'. Solid Hardware resume dialog. Use real tree-view to display list of devices and properties. Implement search and copy to clipboard for hacking purpose and help end users to report problem in bug files. Add Refresh button to list new hot-plugged hardwares. Related: bug 393416, bug 379970, bug 381729, bug 412466, bug 431107 M +171 -183 core/libs/dialogs/solidhardwaredlg.cpp M +2 -0 core/libs/dialogs/solidhardwaredlg.h https://invent.kde.org/graphics/digikam/commit/1d69260946da53b92067105224468723482e2f8c Git commit cdee9fb951c3f1b3aa354535174eb7c232a241eb by Gilles Caulier. Committed on 10/01/2021 at 16:02. Pushed by cgilles into branch 'master'. Solid info dialog: add new tab with hotplug device events. With this kind of tool, we can idenitfy quickly which device with properties is plug/unplug and detected by Solid framework. As exemple, in this screenshoot, see my Iphone 7 connected and disconnected from USB port: https://i.imgur.com/dfL1Grs.png Of course, if nothing happen in this view, this want mean that device is not recognized at all from Solid framework, and end-user need to report this problem to Solid team. Related: bug 393416, bug 379970, bug 381729, bug 412466, bug 431107 M +14 -4 core/libs/dialogs/infodlg.cpp M +5 -4 core/libs/dialogs/infodlg.h M +96 -3 core/libs/dialogs/solidhardwaredlg.cpp M +3 -0 core/libs/dialogs/solidhardwaredlg.h https://invent.kde.org/graphics/digikam/commit/cdee9fb951c3f1b3aa354535174eb7c232a241eb I am also interested in getting this work on Windows. libgphoto2 PR fixes for mingw: https://github.com/gphoto/libgphoto2/pull/698 mxe PR for enablement of libgphoto2: https://github.com/mxe/mxe/pull/2697 I rebuilt digikam-7.3.0 with the patched libgphoto2-2.5.27 on mingw: ... -- libgphoto2 found......................... YES (optional) ... -- Found Gphoto2: /root/digikam/project/bundles/mxe/build.win64/usr/x86_64-w64-mingw32.shared/lib/libgphoto2.dll.a.. -- libgphoto2 found : TRUE -- libgphoto2 version : 2.5.27 -- libgphoto2 includes : /root/digikam/project/bundles/mxe/build.win64/usr/x86_64-w64-mingw32.shared/include/gphoto2 -- libgphoto2 libraries: /root/digikam/project/bundles/mxe/build.win64/usr/x86_64-w64-mingw32.shared/lib/libgphoto2.dll.a;/root/digikam /project/bundles/mxe/build.win64/usr/x86_64-w64-mingw32.shared/lib/libgphoto2_port.dll.a;/root/digikam/project/bundles/mxe/build.win64/ usr/x86_64-w64-mingw32.shared/lib/libusb-1.0.dll.a -- libgphoto2 API version >= 2.5 ... I verified that the libgphoto2 dlls are installed by the installer, but still nothing. After hitting the autodetect button, no camera is found and in the manual camera add dialog there is nothing listed. Any pointers what's missing to get it working? Hi, great to see a MinGW support of libgphoto. Check if config files are not missing after installation. Look how RPM under linux install files on the system from this library, and try to reproduce it under Windows. Best Gilles Caulier Look the list of files installed by libgphoto2 under Centos 8 (last section on the bottom): http://rpmfind.net/linux/RPM/centos/8-stream/appstream/x86_64/Packages/libgphoto2-2.5.16-3.el8.x86_64.html Don't forget that installing libgphoto2 .dll + .lib files is not enough. You need to parse all the binaries files provided by libgphoto2 compilation to found external dependencies, as libusb for ex. The Python script to build Windows installer for digiKam do the job. Look here : https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/mxe/rll.py Gilles Caulier It seems I am slowly progressing. There were several problems. I will PR more patches to mxe, libgphoto2 upstreams and also to digiKam. At the moment under Win 10 it successfully detects the camera and adds it to the import list (Canon EOS 500D in my case). It also successfully detects the free space in the camera, but unfortunately during the download, when the download dialog opens, it outputs error that it cannot connect to the camera. It's the same with the generic USB PTP camera. At the moment I have libgphoto2 without EXIF support, I don't know whether it can be related. I will try enabling libgphoto2 full debug output and hopefully will find out more. Related digiKam PR (just for the reference, it's unrelated to the comment 19): https://invent.kde.org/graphics/digikam/-/merge_requests/133 Another digiKam PR: https://invent.kde.org/graphics/digikam/-/merge_requests/135 libexif mxe PR: https://github.com/mxe/mxe/pull/2700 The camera is detected fine, but I am getting: GP_ERROR_IO_USB_CLAIM (Could not claim the USB device -53) from the libgphoto2 when trying to access it. I tried multiple cameras, but it's still the same. Running under admin account. I tried to uninstall the windows MTP driver, but then it seems it cannot talk to the device, so it seems the MTP driver has to be installed if winusb is used. I will try with the gphoto2 CLI. I think that libgphoto2 needs libusb1 at run time (or something like that). And yes the Gphoto2 CLI tool will help to investigate. In digiKam, we call the libgphoto2 API which is used in Gphoto2 CLI tool. If i remember, the Gphoto2 CLI tool has a debug mode which can be turn on with a env. variable. I don't know if it will work under windows. Else you can ask help to Marcus Meissner who maintain the project. I CC him for info to this file. Gilles Caulier Another libgphoto2 PR: https://github.com/gphoto/libgphoto2/pull/705/ (In reply to caulier.gilles from comment #23) > I think that libgphoto2 needs libusb1 at run time (or something like that). > Yep, I already had it (libusb1). I verified it's bundled and loaded (I patched the bundler script, I will PR the changes later). > And yes the Gphoto2 CLI tool will help to investigate. In digiKam, we call > the libgphoto2 API which is used in Gphoto2 CLI tool. > Yep, I noticed, I also enabled the additional digikam debug output related to the libgphoto2, by `#define GPHOTO2_DEBUG 1`. > If i remember, the Gphoto2 CLI tool has a debug mode which can be turn on > with a env. variable. I don't know if it will work under windows. > Yes, this will be my next step, cross-compile gphoto2, enable full debug and investigate. If it is libgphoto2 bug, I will open libgphoto2 PR or issue. > Else you can ask help to Marcus Meissner who maintain the project. I CC him > for info to this file. > Thanks. FTR I am testing on the Windows 10, the latest stable build. I am using the latest master of the digiKam. (In reply to Jaroslav Skarvada from comment #26) > FTR I am testing on the Windows 10, the latest stable build. I am using the > latest master of the digiKam. 64 bit Windows 10, 64 bit digiKam/libraries build. yes, digiKam is only compiled in 64 bits now under Windows, as 32 bits is limited with memory allocation and introduce dysfunctions with large memory usage features, as face workflow for example. Gilles I finally cross-compiled gphoto2 in the mxe with some effort, spotted gphoto2 bug: https://github.com/gphoto/gphoto2/issues/448 I finally got it working, gphoto2 upstream bug: https://github.com/gphoto/libgphoto2/issues/706 TLDR the digiKam has to be running under the admin account and I had to replace the windows PTP drivers for all devices I want to use with the digiKam by the WinUSB libusb driver. Then such devices cannot be used with the native windows PTP (e.g. from the explorer). The tool called 'Zadig' can help with the selective filtering and re-installation of the drivers for individual devices. So, it's usable with some compromises. I will PR the digiKam patches for enablement. It seems windows has some nice native PTP API, it would be nice to implement support for it in digiKam, it would simplify things. Also probably dupes (maybe there are more): https://bugs.kde.org/show_bug.cgi?id=398061 https://bugs.kde.org/show_bug.cgi?id=379970 To implement a Windows native support in digiKam import tool, this interface must be re-implemented : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/backend/dkcamera.h As it's already done for Gphoto2 backend : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/backend/gpcamera.h ...and USB Mass Storage backend : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/backend/umscamera.h Typically, the UMS implementation is a good start to port to Windows native. Gilles Caulier (In reply to caulier.gilles from comment #32) > To implement a Windows native support in digiKam import tool, this interface > must be re-implemented : > > https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/ > backend/dkcamera.h > > As it's already done for Gphoto2 backend : > > https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/ > backend/gpcamera.h > > ...and USB Mass Storage backend : > > https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/ > backend/umscamera.h > > Typically, the UMS implementation is a good start to port to Windows native. > > Gilles Caulier OK, just keeping this idea for somebody else as an RFE. Unfortunately, at the moment, I am out of time to implement this myself :) I got it working even for non-admin user. I also tried the libusb-win32 driver, but it's crashing during download of the photos. The WinUSB driver seems to work the most reliable way. Steps how to install it: - logon as admin - download Zadig (https://zadig.akeo.ie/) and run it - click Options->List All Devices - connect camera and switch it on - locate it in the Zadig device list, check whether the USB VID/PID matches - select the WInUSB driver (I used WinUSB v6.1.7600.16385) - click Install Driver - wait several minutes (this can take really long time, because it's usually creating restore point) - when the driver is installed, disconnect and reconnect the camera - logon as normal user If you want to restore the original driver to be able to do the native PTP from the explorer: - logon as admin - open device manager - connect camera and switch it on - the camera should appear in the device manager - right click it and select uninstall, check remove installation files - disconnect and reconnect the camera A possibly relevant merge request was started @ https://invent.kde.org/graphics/digikam/-/merge_requests/136 digiKam PR: https://invent.kde.org/graphics/digikam/-/merge_requests/136 Unofficial unsupported build for testing (it's built from the v7.3.0 tag): https://jskarvad.fedorapeople.org/digiKam/digiKam-7.3.0-Win64.exe Apply patch from Jaroslav Škarvada to fix broken compilation under Fedora 33 CCMAIL: jskarvad@redhat.com FIXED-IN: 7.6.0 M +4 -5 core/libs/dngwriter/extra/xmp_sdk/XMPCore/source/XMPUtils.cpp https://invent.kde.org/graphics/digikam/commit/248347f4ab8118370ede9020d9123d4022b50792 Git commit 445e681592c2c7893af72bbcf1ce8ec5f42bae74 by Gilles Caulier. Committed on 20/01/2022 at 07:59. Pushed by cgilles into branch 'master'. add url alternative for annonymous access to git repository CCMAIL: jskarvad@redhat.com FIXED-IN: 7.6.0 M +3 -0 project/bundles/appimage/config.sh M +3 -0 project/bundles/macports/config.sh M +3 -0 project/bundles/mxe/config.sh https://invent.kde.org/graphics/digikam/commit/445e681592c2c7893af72bbcf1ce8ec5f42bae74 Git commit debfe81f73f2099537d479059a0c58d15667a83b by Gilles Caulier. Committed on 20/01/2022 at 08:04. Pushed by cgilles into branch 'master'. Apply patch from Jaroslav Škarvada to fix unzip arguments to extract ExifTool archive CCMAIL: jskarvad@redhat.com FIXED-IN: 7.6.0 M +1 -1 project/bundles/mxe/04-build-installer.sh https://invent.kde.org/graphics/digikam/commit/debfe81f73f2099537d479059a0c58d15667a83b Git commit fef060f7cae15b12b9553d0cb0d24b3b5b61d3a4 by Gilles Caulier. Committed on 20/01/2022 at 08:11. Pushed by cgilles into branch 'master'. Apply patch from Jaroslav Škarvada silent marble libraries copy under MXE for Fedora 33 CCMAIL: jskarvad@redhat.com FIXED-IN: 7.6.0 M +2 -2 project/bundles/mxe/02-build-extralibs.sh https://invent.kde.org/graphics/digikam/commit/fef060f7cae15b12b9553d0cb0d24b3b5b61d3a4 Git commit 900e6e71de416481061762541b8ccb73764b6a55 by Gilles Caulier. Committed on 20/01/2022 at 08:58. Pushed by cgilles into branch 'master'. Apply patch from Jaroslav Škarvada to enable libgphoto2 under Windows with MXE build. CCMAIL: jskarvad@redhat.com M +19 -21 core/CMakeLists.txt M +1 -1 project/bundles/mxe/01-build-mxe.sh M +11 -3 project/bundles/mxe/04-build-installer.sh M +8 -0 project/bundles/mxe/installer/digikam.nsi https://invent.kde.org/graphics/digikam/commit/900e6e71de416481061762541b8ccb73764b6a55 All patches from Jaroslav Skarvada are applied. MXE build system need to be rebuild to include libgphoto2. This will be done in few days. Gilles Caulier *** Bug 379970 has been marked as a duplicate of this bug. *** *** Bug 412466 has been marked as a duplicate of this bug. *** *** Bug 398061 has been marked as a duplicate of this bug. *** Hi Jaroslav, I applied all your patches in git/master. Next digiKam 7.6.0 will support officially Gphoto2 under Windows... but, no Gphoto2 camera driver is listed in setup dialog if i want to select one manually. https://i.imgur.com/vVLZFDf.png On debugView, the trace indicate that code is properly compiled with libgphoto2 API but not driver is available : [3700] digikam.import: Number of cameras supported: 0 [3700] digikam.import: Number of ports supported: 0 This trace come from this code : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/backend/gpcamera.cpp#L1691 https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/import/backend/gpcamera.cpp#L1738 This want mean that libgphoto2 drivers dlls are not loaded by Gphoto2 at startup. These dlls are located here under windows : https://i.imgur.com/BbQ0LPA.png These paths are right as under MXE, libgphoto2 has a patch to force the location of these directories as relative of executable : https://github.com/mxe/mxe/blob/master/src/libgphoto2-2.patch#L50 https://github.com/mxe/mxe/blob/master/src/libgphoto2-2.patch#L87 In fact CAMLIBS and IOLIBS env.variables are overwritten in source code. I think this kind of rules is fine. The Q is : why the dll drivers are not listed in the setup camera list as under Linux ? https://i.imgur.com/HhMCumx.png Note: The problem is exactly the same under MacOS : https://i.imgur.com/JG5hV7g.png Gilles Caulier Hi Jaroslav, I just compiled a Windows installer including Gphoto2 support. It's here : https://files.kde.org/digikam/experimental/digiKam-7.6.0-20220125T171219-Win64-Gphoto2.exe.mirrorlist Gilles Caulier Hi Jaroslav, Correction. I upgraded libgphoto2 under MacOS from 2.5.27 to 2.5.28, and now problem disappear : https://i.imgur.com/elfzIcG.png Perhaps the problem is the same under Windows and MXE package of libgphoto2 needs to be update to last stable... Best Gilles (In reply to caulier.gilles from comment #48) > Hi Jaroslav, > > Correction. I upgraded libgphoto2 under MacOS from 2.5.27 to 2.5.28, and now > problem disappear : > > https://i.imgur.com/elfzIcG.png > > Perhaps the problem is the same under Windows and MXE package of libgphoto2 > needs to be update to last stable... > > Best > > Gilles Thanks for applying the patches. So does it work now? IIRC there was some problem with the libusb on the MXE side, but it should be solved soon: https://github.com/mxe/mxe/commit/01f72f5347f38fd32a3dedacee0ba16f315006fe If you have the affected MXE version you could patch it downstream. (In reply to Jaroslav Skarvada from comment #49) > Thanks for applying the patches. So does it work now? IIRC there was some > problem with the libusb on the MXE side, but it should be solved soon: > https://github.com/mxe/mxe/commit/01f72f5347f38fd32a3dedacee0ba16f315006fe > If you have the affected MXE version you could patch it downstream. The upstream fix is currently here: https://github.com/mxe/mxe/commit/5e2f623d08b02cc4604a68dfa75df4b0d79b789b Hi Jaroslav, The libusb fix must be included in my MXE installation, as i just rebuild all from scratch 2 days ago. Also, the way to list all gphoto2 camera drivers in digiKam do not depand of libusb. There is no communication here, it just a flat list of device supported by installed dlls from libgphoto2. As the problem also reproducible under MacOS have been simply fixed by upgrading libgphoto2 from 2.5.27 to 2.5.28, i open a file in MXE to update the libghoto2 package : https://github.com/mxe/mxe/issues/2756 Gilles Hum 13 hours ago the commit to MXE repository. So, i will try to update MXE packages installation now to see if it fix the problem. Gilles Right, MXE update is required first : ---------- Updating MXE Depuis https://github.com/mxe/mxe 21ff2254..5e2f623d master -> origin/master Mise à jour 21ff2254..5e2f623d Fast-forward src/libexif-1-fixes.patch | 21 +++++++++++++++++++++ src/libexif.mk | 2 +- src/libgphoto2.mk | 1 - 3 files changed, 22 insertions(+), 2 deletions(-) create mode 100644 src/libexif-1-fixes.patch ---------- Building cross-compiler for MXE [git-log] 5e2f623d libgphoto2: allow libusb-1 detection ---------- Building digiKam low level dependencies with MXE make: rien à faire pour « expat ». make: rien à faire pour « zlib ». make: rien à faire pour « pthreads ». [build] libexif x86_64-w64-mingw32.shared ... Gilles Hi Jaroslav, I rebuild libexif + libgphoto with the update of MXE, rebuild the digiKam installer. But, no chance, the list of libgphoto2 drivers still empty in setup dialog. So an update of MXE libgphoto2 to last 2.5.28 is the next stage. I seen that MXE team ask for a PR in github : https://github.com/mxe/mxe/issues/2756#issuecomment-1022127307 Gilles (In reply to caulier.gilles from comment #54) > Hi Jaroslav, > > I rebuild libexif + libgphoto with the update of MXE, rebuild the digiKam > installer. > But, no chance, the list of libgphoto2 drivers still empty in setup dialog. > > So an update of MXE libgphoto2 to last 2.5.28 is the next stage. I seen that > MXE team ask for a PR in github : > > https://github.com/mxe/mxe/issues/2756#issuecomment-1022127307 > > Gilles Thanks for info. Probably somebody broke something somewhere. I currently do not have digikam build environmet ready, but I could setup it if needed and check it. It's also possible to temporally bundle the gphoto binaries into the digikam installator and run them with the full debug enabled to see what's going there (I debugged it previously this way). You may also try rebuilding the libgphoto2 with the legacy libusb enabled (i.e try dropping the --with-libusb=no from the mxe). Maybe there is some wrong ifdef in the code. You also need to follow the steps from the comment 34, because normally the windows mass storage or PTP driver will take over the libgphoto2/libusb drivers. Hi Jaroslav, I don't take a care about the comment #34. To automatize the process, we need to do the following steps to be able to use libgphoto2 in digiKam under Windows : 1/ checkout and cross-compile with MXE : https://github.com/pbatard/libwdi 2/ install the dlls within the DK installer. 3/ use the API : https://github.com/pbatard/libwdi/wiki/Usage * to load usb/ptp driver before to use libgphoto2 API * to unload usb/ptp driver after to use libgphoto2 API If we want to be generic : 1/ must be done in MXE, 2/ in NSIS DK installer, 3/ in ligphoto2 API as well The less generic way : 1/ in DK installer build, 2/in NSIS DK installer, 3/ in DK code. Right ? Gilles Hi Jaroslav, New 7.6.0 pre-release Windows installer is online with last libgphoto2 2.2.58. https://files.kde.org/digikam/ List of drivers still empty in config dialog : https://i.imgur.com/9MVKfXr.png So the problem is located probably in gphoto2 code... Did you seen my comment #58 Best regards Gilles Caulier (In reply to caulier.gilles from comment #59) > Hi Jaroslav, > > New 7.6.0 pre-release Windows installer is online with last libgphoto2 > 2.2.58. > > https://files.kde.org/digikam/ > > List of drivers still empty in config dialog : > > https://i.imgur.com/9MVKfXr.png > > So the problem is located probably in gphoto2 code... > > Did you seen my comment #58 > > Best regards > > Gilles Caulier I will prepare the build environment and I will try to debug the problem. Regarding the libwdi I will take a look, it would be definitely improvement to make it working out-of-the-box without USB drivers hacking. I built the git head (at the time I started with it it was v7.5.0-322-gb6a672426b) and it works for me. This time it was nearly straightforward experience, I only hit one MXE FTBFS bug and created PR for it (https://github.com/mxe/mxe/pull/2761). I think you hit another bug, because it seems the digiKam Start panel LNK (installed as C:\ProgramData\Microsoft\Windows\Start Menu\Programs\digiKam 7.3.0\digiKam.lnk) has for some reason workdir set to the C:\Program Files\digiKam\bin, but the libgphoto drivers are loaded from the current dir which means if you start digiKam from the Start menu it will not work. You need to either: a) start digiKam from the C:\Program Files\digiKam or b) edit the LNK file to have the workdir set to the C:\Program Files\digiKam (i.e. without the bin) or c) move the camera drivers (./libgphoto2 and ./libgphoto2_port directories) to the ./bin directory I don't know what's the best solution. Unfortunately, we cannot compile the libgphoto2 with the absolute path (because it is not known before the installation) and IMHO the libgphoto2 API currently doesn't allow changing the load path dynamically at the runtime (but there is an RFE for it). Btw the following dependencies are needed for compilation under Fedora 34, it can be installed by: # dnf install autoconf automake bash bison bzip2 cmake extra-cmake-modules flex gcc-c++ gdk-pixbuf2-devel gettext git git gperf icoutils intltool libtool lzip make nsis openssl openssl-devel patch perl python python3-lxml p7zip qt5-qtbase-devel ruby sed subversion unzip wget xz Is there any wiki or something where I could put this information? I think it could be useful for more people. Regarding the libwdi, I could try to get it into the MXE, but it seems it needs bundling of the libusb windriver which I currently don't know whether it's possible from the MXE, but I will check it. Then it should be matter of few libwdi API calls (which could be copied from the examples section of the documentation). I think the camera dialog will have to be patched and the install button will have to be added. Unfortunately, the libwdi API doesn't support uninstallation of the drivers, thus the driver will have to be manually uninstalled by users (if required), but it shouldn't be blocker. (In reply to Jaroslav Skarvada from comment #62) > Regarding the libwdi, I could try to get it into the MXE, but it seems it > needs bundling of the libusb windriver which I currently don't know whether > it's possible from the MXE, but I will check it. Then it should be matter of > few libwdi API calls (which could be copied from the examples section of the > documentation). I think the camera dialog will have to be patched and the > install button will have to be added. Unfortunately, the libwdi API doesn't > support uninstallation of the drivers, thus the driver will have to be > manually uninstalled by users (if required), but it shouldn't be blocker. The libwdi requires the libusb-win32 which provides the 'sys' drivers. Unfortunately, I wasn't able to compile the libusb-win32 with the recent mingw. It seems it uses obsoleted winddk (for xp/vista). Fixing it to compile with the recent mingw will require porting it to the recent wdk (https://github.com/mcuee/libusb-win32/issues/30) which is currently out of my scope. You could build the libwdi out-of-the mxe tree and bundle the libusb-win32 sys driver as a binary blob (i.e. download the compiled binary sys driver from the internet). Maybe this is inefficient overhead. I think it could work fine with the original MS winusb driver. Just the INF file unbinding the native PTP driver not to take over could be enough. This is what the Zadig also supports, but unfortunately for the libwdi you will have to compile with the `--with-wdkdir="<dir>"` to embed the WDK redistributable components files. This will probably require downloading the WDK, which is something that cannot be done in the mxe. But again you could probably compile the libwdi out-of-the mxe tree and bundle the WDK redistributable components there (but I don't know what the MS license allows). *** Bug 462225 has been marked as a duplicate of this bug. *** We currently switch from MXE to VCPKG framework to build digiKam for Windows. The port is under progress. I hope finalize this step in next week. In VCPKG project i see this entry about Gphoto2 under Windows, especially this comment : https://github.com/Microsoft/vcpkg/issues/5075#issuecomment-633519224 If M$ can provide a patch to use natively Gphoto2 under Windows, as the camera interface is out-to -date, this will be nice... Gilles Caulier Created attachment 162729 [details] attachment-890420-0.html It' a good news, Frank Zappa said “*A mind is like a parachute. It doesn't work if it is not open*.” Keep progressing digikam for a long time... Jean-Pierre Boucher Le lun. 30 oct. 2023 à 14:22, <bugzilla_noreply@kde.org> a écrit : > https://bugs.kde.org/show_bug.cgi?id=398166 > > --- Comment #65 from caulier.gilles@gmail.com --- > We currently switch from MXE to VCPKG framework to build digiKam for > Windows. > > The port is under progress. I hope finalize this step in next week. > > In VCPKG project i see this entry about Gphoto2 under Windows, especially > this > comment : > > https://github.com/Microsoft/vcpkg/issues/5075#issuecomment-633519224 > > If M$ can provide a patch to use natively Gphoto2 under Windows, as the > camera > interface is out-to -date, this will be nice... > > Gilles Caulier > > -- > You are receiving this mail because: > You are on the CC list for the bug. |
