[kdeconnect] [Bug 442782] KDE Connect is draining battery
https://bugs.kde.org/show_bug.cgi?id=442782 --- Comment #4 from Jaroslav Skarvada --- +1, please add option to disable and manual enable only when needed. Otherwise it's unusable for me. Moreover, it's better for security not to run services you don't need at the moment. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 442782] KDE Connect is draining battery
https://bugs.kde.org/show_bug.cgi?id=442782 Jaroslav Skarvada changed: What|Removed |Added CC||jskar...@redhat.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #63 from Jaroslav Skarvada --- (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=""` 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). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #62 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #61 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #60 from Jaroslav Skarvada --- (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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #57 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #56 from Jaroslav Skarvada --- 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 are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #55 from Jaroslav Skarvada --- (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 are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #50 from Jaroslav Skarvada --- (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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #49 from Jaroslav Skarvada --- (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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #36 from Jaroslav Skarvada --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #34 from Jaroslav Skarvada --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #33 from Jaroslav Skarvada --- (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 :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #31 from Jaroslav Skarvada --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #30 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #29 from Jaroslav Skarvada --- I finally cross-compiled gphoto2 in the mxe with some effort, spotted gphoto2 bug: https://github.com/gphoto/gphoto2/issues/448 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #27 from Jaroslav Skarvada --- (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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #26 from Jaroslav Skarvada --- FTR I am testing on the Windows 10, the latest stable build. I am using the latest master of the digiKam. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #25 from Jaroslav Skarvada --- (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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #24 from Jaroslav Skarvada --- Another libgphoto2 PR: https://github.com/gphoto/libgphoto2/pull/705/ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #22 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #21 from Jaroslav Skarvada --- Another digiKam PR: https://invent.kde.org/graphics/digikam/-/merge_requests/135 libexif mxe PR: https://github.com/mxe/mxe/pull/2700 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #20 from Jaroslav Skarvada --- Related digiKam PR (just for the reference, it's unrelated to the comment 19): https://invent.kde.org/graphics/digikam/-/merge_requests/133 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 --- Comment #19 from Jaroslav Skarvada --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398166] Import from camera doesn't find path
https://bugs.kde.org/show_bug.cgi?id=398166 Jaroslav Skarvada changed: What|Removed |Added CC||jskar...@redhat.com --- Comment #16 from Jaroslav Skarvada --- 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? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 438984] Uncomplete report with C++ and --track-origins=yes
https://bugs.kde.org/show_bug.cgi?id=438984 --- Comment #1 from Jaroslav Skarvada --- The reproducer should be: valgrind --log-file=/var/tmp/log --trace-origins=yes powertop -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 438984] New: Uncomplete report with C++ and --track-origins=yes
https://bugs.kde.org/show_bug.cgi?id=438984
Bug ID: 438984
Summary: Uncomplete report with C++ and --track-origins=yes
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: jskar...@redhat.com
Target Milestone: ---
SUMMARY
Install powertop-2.14
STEPS TO REPRODUCE
1. valgrind --log-file=/var/tmp/log --trace-origins=y powertop
2.
3.
OBSERVED RESULT
==6543== Conditional jump or move depends on uninitialised value(s)
==6543==at 0x1404A2: global_power() (measurement.cpp:89)
==6543==by 0x14051A: global_sample_power() (measurement.cpp:104)
==6543==by 0x1220A8: one_measurement(int, int, char*) (main.cpp:246)
==6543==by 0x1179DB: main (main.cpp:543)
==6543== Uninitialised value was created by a heap allocation
==6543==at 0x483A0F4: operator new(unsigned long, std::nothrow_t const&)
(vg_replace_malloc.c:385)
==6543==by 0x13E1EF: sysfs_power_meters_callback(char const*)
(measurement.cpp:144)
==6543==by 0x121553: process_directory(char const*, void (*)(char const*))
(lib.cpp:455)
==6543==by 0x1219AE: UnknownInlinedFun (measurement.cpp:174)
==6543==by 0x1219AE: powertop_init(int) [clone .part.0] (main.cpp:403)
==6543==by 0x1179A8: UnknownInlinedFun (extech.cpp:280)
==6543==by 0x1179A8: main (main.cpp:518)
EXPECTED RESULT
Pointer from where the uninitialized value is coming from. In the current
output there is missing step the user has to find out manually, see the
ADDITIONAL INFORMATION bellow.
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma: Fedora 33
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
valgrind-3.16.1
ADDITIONAL INFORMATION
measurement.cpp:
076: double global_power(void)
077: {
079: bool global_discharging = false;
080: double total = 0.0;
081: unsigned int i;
082:
083: for (i = 0; i < power_meters.size(); i++) {
084 global_discharging |= power_meters[i]->is_discharging();
085: total += power_meters[i]->power();
086: }
087:
088: /* report global time left if at least one battery is discharging
*/
089: if (!global_discharging)
090: return 0.0;
091:
092: all_results.power = total;
093: if (total < min_power && total > 0.01)
094:min_power = total;
095: return total;
096: }
The line 89 with 'if (!global_discharging)' is not much helpful, because on
line 79 the global_discharging is explicitly initialized to 'false'. It's
actually the line 84 where the problem is (and it's missing from the valgrind
report). On the line 84 it's the call 'power_meters[i]->is_discharging()' which
is causing the problem.
measurement.h
32: class power_meter {
33: bool discharging;
34: public:
35: virtual ~power_meter() {};
36:
37: virtual void start_measurement(void);
38: virtual void end_measurement(void);
39: virtual double power(void);
40:
41: virtual double dev_capacity(void)
42: {
43: return 0.0; /* in Joules */
44: }
45:
46: virtual void set_discharging(bool d)
47: {
48: discharging = d;
49: }
50:
51: virtual bool is_discharging()
52: {
53: return discharging;
53: }
55: };
So the real problem is line 53, which leads to the line 33 which is missing the
explicit initialization. But these steps are missing from the valgrind report
and needs to be found out manually.
--
You are receiving this mail because:
You are watching all bug changes.
