On Fri, Aug 19, 2016 at 10:50 AM, Hermann Hamann <hermann-ham...@web.de> wrote: > Hi Tormod, > thank you for your expertise; now I see clearer. > >> < Why it crashed? >> I don't know. > > I will send you a crash dump later.
Great, thanks. > >> <If you want to use libusb-1.0 backend, you need to have libusb-1.0.dll in >> <the system and better use WinUSB driver for your device. >> >> I want the backend that is in the registry. > >>pyusb by default looks for libusb1 first > > < .... you must select backend explicitly. > > Well how can I? I do not know which backend is available on my clients' > machines. You should know! The application that you deliver to your client is your.py + pyusb + libusb backend. If your application is "taking care" of a device you ship this bundle + hardware driver (libusb0.sys or inf declaring WinUSB for the device). If your application is just an extra tool and an existing application already installed a hardware driver that you don't want to interfere with, you better know the application which "owns" the device and which hardware driver it uses, but as you already are aware of, you can also read out the registered hardware driver from the registry. If the existing hardware driver can be either libusb0.sys or winusb.sys, you must bundle all appropriate backends to handle all cases. As I said before, the libusb1 backend should handle both, but due the bug you encounter it seems you will need to bundle both libusb1 and libusb-win32 for now and your application must choose between either as function of the hardware driver, as a workaround for this bug. Again, only if you cannot decide the hardware driver for this device... And whether the client may have other applications using some variety of libusb or not, that is not something you should speculate about, because the other "private" libusb libraries can be modified versions for what you know. If the machine is well administrated, it might have a relatively recent, official libusb installed in the system32 folder, but you probably shouldn't rely on that. Your installation program/instructions should install the libusb DLL that you need. > I can only rely on the driver that was installed for my device and which is > displayed > in the control panel. I suppose the control panel gets it through the > registry. > > << Flexibility comes at a cost. > And what is the cost of reliability? The cost of reliability here is that you shouldn't rely on the convenience auto-detection of already installed libusb backends that pyusb offers as an option. It is provided as a convenience, but as an application programmer you don't have to rely on it. As any other application programmer you should know what is the hardware driver used for the device, and assure the existence of libraries that your program needs. pyusb has the flexibility of working with many backends and thus with many hardware drivers so it gives many possibilities. The cost of flexibility is that is you have choose between all these possibilities, and make sure your choice is implemented. It would be very normal for a program or library to depend on one specific hardware driver. Here pyusb is very flexible. The cost of this flexibility is paid by the pyusb developers, and only your choice of relying on the autodetection convenience is adding to your bill. The client's flexibility to use different hardware drivers will cost you as the application programmer. On the other hand if you know that the device uses the libusb0.sys hardware driver, and you know that the libusb-win32 backend works well with your device, you just select this backend in your application and bundle libusb-win32 with it. You also make sure that this libusb0.dll is the one picked up by pyusb by having it first in the path that pyusb uses for DLL discovery. This is how other Windows applications make sure they have the right DLL's (and version) loaded, for instance by throwing them into the directory where the executable is. Or you follow the suggestion in the pyusb manual https://github.com/walac/pyusb/blob/master/docs/tutorial.rst#specifying-libraries-by-hand (with the only catch that you might have to find out if the host is 32 or 64 bit). > > <And the pyusb application currently uses a DLL search to select default > library > <backend, regardless of the device. > > Well I rank the registry higher in authority than the library search order. It looks like you are mixing up library backend and driver. The registry will tell you which driver (part of OS) is handling the device. The OS doesn't dictate what DLL's you make up your application from. From the OS point of view, your application includes pyusb and libusb backend. The libusb backend is not a driver or service, it is a piece of code linked into your application (linked at run-time in the case of pyusb). > > > <Hermann, in your case you are probably better off selecting the > <libusb0 backend in your python application, if you know that your > <device requires libusb0.sys. Otherwise, register the device for WinUSB > <(with .inf file or Zadig), make sure a known good libusb1.dll is > <installed in the path (before any third party libusb1.dll) and select > <the libusb1 backend in your python application for good measure. > > Well I am a bit confused when regarding recommendations for driver > installation. > The tutorial recommends the inf-wizard and libusb0 and so I did and it works > fine. Which exact tutorial? That must be for the libusb-win32 backend. > Well I can instruct my clients to do the same and hardcode pyusb0 into my > program. BTW, do you actually mean pyusb0 (0.4) or libusb0? It actually gets really fun if you have a pyusb 0.4 program, that either runs through pyusb 0.4 (and its possible backends) or through the pyusb 1.0 legacy mode (and thus the backend selection we have talked about) - a lot more combinations possible and auto-selections that the poor 0.4 program wouldn't know about. I remember trying to draw a chart of these once... This gets even more complicated with Linux factored in, where many supported distributions still have pyusb 0.4 so making one pyusb application that works everywhere is challenging, at least without bundling your own pyusb, and python, and libusb - for each platform... > So much about flexibility. Flexibility is not the same as autodetection. And the autodetection actually works as intended. Just the above mentioned bug may have ruined the result. Or the 3rd party libusb1.dll that was first in your path is somehow broken - let us know if you can reproduce with the official, latest libusb. > > <BTW, Hermann's example patch hardcodes "ControlSet002" which I believe > <should be "CurrentControlSet", unless there are better ways to find > > I found this with a registry editor search. I do not understand enough to > judge the generality of this approach. > > <(e.g. different serial numbers but same vid/pid) can have different > <Service values, and I am not sure how the patch deals with that. > I would not care, nobody will have two same oscilloscopes on its computer. The Windows registry contains different instances for each serial number. If the oscilloscopes have no USB serial number, there will be a new instance for every USB hardware port address used. In theory you can have different drivers associated depending on which USB port it is plugged into :) > > Thank you again for your effort, this makes my issue obsolete an I will not > open it. Glad I could help. Your issue is at a level higher than pyusb. Tormod > > Sincerely Hermann ------------------------------------------------------------------------------ _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
