Hi Tormod,
The first thing I want to mention, before discussion your issue (which
is something that should have appeared in the ChangeLog, but that I
completely forgot to add), is that support for the libusb-win32 and
libusbK drivers in libusbx is still very EXPERIMENTAL at this stage, and
will continue to be so for the few next releases.
Especially, support for these drivers is not feature complete yet,
therefore we make no guarantee that all the functions will work as
expected, if at all.
This being said:
On 2012.09.30 11:23, Tormod Volden wrote:
> So I used Zadig to install
> libusbK for the device, then switched back to libusb-win32 again. And
> now it worked.
You're absolutely right, and I will need to update libwdi/Zadig so that
the libusbK dll is installed along the libusb-win32 driver.
At the moment, the libusbK DLL is actually extracted when selecting the
libusb-win32 driver, but it's not referenced in the inf, so it doesn't
get installed.
> 1) I think it should be better documented that the libusb-win32 driver
> backend either uses the libusbK or WinUSB driver and does not function
> with libusb-win32 alone.
Indeed. libusbx support for libusb-win32 requires the libusbK DLL to be
available.
> Although I am not sure I understand this
> correctly, libusb-win32 is also a "driver" that can access devices
> without the help of libusbK or WinUSB, right?
It does, but we use the libusbK DLL to access it.
The reason is that, thanks to the good efforts of Travis, libusbK
provides a single API for libusb-win32 and libusbK support, which is
similar to the WinUSB API we are already using. Of course, since we are
resource constrained for development, this is the API we used, as it
reduced the effort needed at least in half. If we were to add support
for standalone libusb-win32, without using the convenience of the
libusbK DLL, it would take a lot more time (as well as introduce more
potential points of failure, since it would increase complexity), and
considering that our resources are limited, this doesn't look like the
smart approach.
Also, ultimately, we plan to integrate the libusbK library part into
libusbx, in one form or another, so that only the drivers are required,
in which case the requirement for libusbK.dll when using the
libusb-win32 driver from libusbx will be eliminated. But this too will
require some resources, so it is unlikely to happen for a year or two at
best.
> 2) The same commit message says "In case libusbk.dll is not present,
> fall back to WinUSB". Apparently, this path did not work in my case.
> Have I found a bug or am I missing something?
Just as is the case for the libusbK and libusb-win32 drivers, the
libusbK DLL also allows access to a WinUSB driver through the DLL API
rather than through the WinUSB DLL API, and this is what the note above
is about.
In other words, if both libusbK and WinUSB are present, libusbx will
access the WinUSB driver through the libusbK DLL. But if the libusbK DLL
isn't there, it will access the WinUSB driver through the WinUSB DLL.
NB: The libusbK DLL ultimately forwards the calls to the WinUSB DLL, so
in both cases access to the WinUSB driver goes through WinUSB DLL, but
this is beyond the point here.
I should have written "In case libusbk.dll is not present, fall back to
WinUSB.dll", because the commit message is not about the drivers at all,
but the DLL that sits on top of them.
> Anyway, avoiding the limitations of WinUSB (in particular the
> inability to send a reset command) is my motivation for using
> libusb-win32
OK. There are provisions for reset, but they haven't been tested yet. If
you need reset, I suggest you wait for the next version (or the version
after that, as we're sorting a version bump at the moment).
>Of course, a nice graphical
> presentation of the Windows driver layering would be very welcome :)
1. With libusbK.dll available
libusbx
|
V
libusbK.dll
|
+--------------------+---------------------+
| | |
V V V
WinUSB.dll libusb-win32.dll libusbK driver
| | (libusbk.sys)
V V
WinUSB driver libusb-win32 driver
(WinUSB.sys) (libusb0.sys)
NB: libusb-win32.dll is really named libusb0.dll, but that doesn't
really matter for this illustration
2. Without libusbK.dll present. This is done to preserve compatibility
with pre 1.0.13 applications, as we would otherwise have to ask all end
users to install the libusbK.dll.
libusbx
|
V
WinUSB.dll
|
V
WinUSB driver
(WinUSB.sys)
Thus, the only piece missing when using libusb-win32, as you found out,
is the installation of the libusbK.dll, and that something that should
be handled in libwdi/Zadig. I'll try to produce a new version of Zadig
that does just that during the week, but I can't promise anything.
Oh, for the sake of completion, note that the libusbK driver actually
installs both the libusbK and libusb-win32 DLLs, which brings me to a
question to Xiaofan:
Should we expect people not to install libusb-win32 using a libwdi
derivative?
Right now, the only reason I see to keep the libusb-win32 DLL install in
K.inf is if we expect someone to just drop a libusb0.sys, which I don't
expect to be a common occurrence, and even then, I would assume that
someone producing their own inf would take care to add libusb0.dll.
Or does the libusbK DLL require access to libusb-win32 API functions,
regardless of whether the driver is present?
I must admit I can't remember what made you guys want to have a K.inf
that installed libusb-win32.dll, and since we're cleaning the DLL
dependencies, we might want to sort both sides.
Regards,
/Pete
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
