Menu
▾
▴
libusb-devel
|
From: Pete B. <pb...@gm...> - 2010-08-19 00:21:28
|
On 2010.08.19 00:51, Xiaofan Chen wrote: > I will try to get the debug log this evening. Thanks. I ran my test on Windows 7 x64 in the same way as you do (using BenchmarkCon.exe and the Benchmark test device), so I'll be interested in finding out what the differences are between your environment and mine. Regards, /Pete |
|
From: Travis <tra...@co...> - 2010-08-19 00:24:17
|
No worries Pete, this certainly sounds like a .NET problem. Lemme look into this first. Regards, Travis > Unhandled Exception: System.BadImageFormatException: An attempt was made > to load > a program with an incorrect format. (Exception from HRESULT: 0x8007000B) > at MonoLibUsb.MonoUsbApi.Init(IntPtr& pContext) |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 01:26:48
|
On Thu, Aug 19, 2010 at 8:24 AM, Travis <tra...@co...> wrote: > No worries Pete, this certainly sounds like a .NET problem. Lemme look into > this first. > >> Unhandled Exception: System.BadImageFormatException: An attempt was made >> to load >> a program with an incorrect format. (Exception from HRESULT: 0x8007000B) >> at MonoLibUsb.MonoUsbApi.Init(IntPtr& pContext) > This particular part may be a .Net problem or my problem. I was putting the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. Maybe I should have put the 64bit one to see if that helps. I will check again. On the other hand, the following program is built with MinGW (32bit, from MinGW.org), so I think to put the MinGW 32bit libusb-1.0.dll (from the binary snapshots) is correct way. D:\work\libusb1win32\Test>lsusb-with-open.exe 1d6b:0001 (bus 0, device 255) 046d:c058 (bus 0, device 1) 1234:0001 (bus 0, device 2) -12:Operation not supported or unimplemented on this platform failed opening device 1234:0001 Anyway, I will check again this evening. -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-08-19 03:02:51
|
Xiaofan Chen wrote: >> This particular part may be a .Net problem or my problem. I was putting >> the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. Maybe >> I should have put the 64bit one to see if that helps. I will check again. Would any user ever have a 32bit libusb-1.0.dll on a 64-bit OS? If so, is that going to need a suffix? Michael |
|
From: Graeme G. <gr...@ar...> - 2010-08-19 04:19:58
|
Michael Plante wrote: > Would any user ever have a 32bit libusb-1.0.dll on a 64-bit OS? If so, is > that going to need a suffix? On MSWin, yes of course, since users may have 32 bit applications. After all, 32 bit applications run on 64 bit MSWin, but not the other way around, so 32 bits makes for simpler builds and deployment. Graeme Gill. |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 05:07:52
|
On Thu, Aug 19, 2010 at 11:01 AM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> This particular part may be a .Net problem or my problem. I was putting >>> the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. Maybe >>> I should have put the 64bit one to see if that helps. I will check again. > > > Would any user ever have a 32bit libusb-1.0.dll on a 64-bit OS? If so, is > that going to need a suffix? Yes there are many 32bit applications even on 64bit OS. No need a suffix. 32bit DLLs are installed to windows\syswow64 directory. 64bit DLLs are installed to windows\system32 directory. You can look at libusb-win32 for an example. For 64bit OS, you need 64bit driver libusb0.sys, but we provide both 32bit libusb0.dll (which goes to windows\syswow64) and 64bit libusb0.dll (which goes to windows\system32). It is the same for WinUSB. The older version of libusb-win32 (0.1.12.x) does use the prefix for both the 64bit driver and the 64bit dll. But we think this is not a good idea. We would use similar scheme like WinUSB (no prefix for 64bit DLL and 64bit driver). Right now I have not seen an installer package for libusb-1.0 for Windows. The binary snapshot is not a full-fledge deployment package. The Zadig utility is not either (only the driver part). Maybe an installer package can be used to deploy libusb-1.0 Windows. It can have several parts, one part is to deploy the dll, one part is to install the development files (header and static/import libraries), one part is for driver installation. Right now all the individual parts are kind of ready, just need an installer (say using Inno Setup). -- Xiaofan |
|
From: Graeme G. <gr...@ar...> - 2010-08-19 06:48:34
|
Xiaofan Chen wrote: > Right now I have not seen an installer package for libusb-1.0 > for Windows. The binary snapshot is not a full-fledge deployment > package. Maybe not, but the .ini installs the driver and the dll's. I guess you could include the headers too if you wanted to. Graeme Gill. |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 11:13:12
|
On Thu, Aug 19, 2010 at 2:47 PM, Graeme Gill <gr...@ar...> wrote: > Xiaofan Chen wrote: > >> Right now I have not seen an installer package for libusb-1.0 >> for Windows. The binary snapshot is not a full-fledge deployment >> package. > > Maybe not, but the .ini installs the driver and the dll's. I guess > you could include the headers too if you wanted to. > I know your inf file installs the driver and the dll. But Pete's Zadig does not really install the libusb-1.0.dll. Pete does not seem to like the dll too much. ;-) -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-19 12:09:50
|
On 2010.08.19 12:12, Xiaofan Chen wrote: > Pete does not seem to like the dll too much. ;-) Shared libraries in system32 are an abomination that should be removed from the face of the earth! More seriously, the reasoning is simple. libwdi is a generic USB driver installer, and there's no guarantee that anybody who installs WinUSB will use it against libusb 1.0. On the other hand, if you install libusb0.sys, you're pretty much guaranteed to want to use libusb-win32, so installing the DLL along with the driver makes sense. Maybe I'll change that when libusb 1.0 supports libusb0.sys, but, if I can get my way, that's unlikely, as I'd rather not have libwdi install a libusb-1.0.dll in system32 ever, else I'm pretty sure I'm going to end up in a situation during development where I'm testing a shared lib based app against a newly built DLL, while in fact I'm using the one installed by libwdi in system32. I'd prefer not piggybacking libusb on top of a driver installer. Besides, I hope we're not going to fall as low as software makers trying to bundle stuff that people might not need, just for the sake of promoting stuff they want to promote. On the other hand, one could create a libusb installer that includes libwdi, to install both the driver and the DLL. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 12:35:39
|
On Thu, Aug 19, 2010 at 8:09 PM, Pete Batard <pb...@gm...> wrote: > On 2010.08.19 12:12, Xiaofan Chen wrote: >> Pete does not seem to like the dll too much. ;-) > > Shared libraries in system32 are an abomination that should be removed > from the face of the earth! ;-) > More seriously, the reasoning is simple. libwdi is a generic USB driver > installer, and there's no guarantee that anybody who installs WinUSB > will use it against libusb 1.0. On the other hand, if you install > libusb0.sys, you're pretty much guaranteed to want to use libusb-win32, > so installing the DLL along with the driver makes sense. I see. I thought the initial goal of libwdi is to install drivers (winusb mainly, libusb0.sys added) to enable the use of libusb-1.0. Now I understand that your goal is more generic. > Maybe I'll change that when libusb 1.0 supports libusb0.sys, but, if I > can get my way, that's unlikely, as I'd rather not have libwdi install a > libusb-1.0.dll in system32 ever, else I'm pretty sure I'm going to end > up in a situation during development where I'm testing a shared lib > based app against a newly built DLL, while in fact I'm using the one > installed by libwdi in system32. I actually agree with you on this one. I had issues with this actually. Now I have removed all the libusb-1.0.dll files from the windows directory. However, once it is more stable, maybe people will want the dll to be inside windows directory. For example, I am not so sure how the language wrapper will work without the dlls in the system directory. In this case, maybe another way to install libusb-1.0 can be devised, say an installer which installs to the default Program Files directory. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-19 12:56:47
|
On 2010.08.19 13:35, Xiaofan Chen wrote: > However, once it is more stable, maybe people will want the dll to > be inside windows directory. For example, I am not so sure > how the language wrapper will work without the dlls in the > system directory. > > In this case, maybe another way to install libusb-1.0 can > be devised, say an installer which installs to the default > Program Files directory. I agree with the need for a libusb installer for regular users. I think the library should be stable enough for that now, and I don't see a problem with this installer copying the DLL to system32, as, unless you're a libusb developer, it makes sense to be able to simply upgrade libusb this way. This installer package could also ask if the header and import libraries should be extracted, and where, so that developer-users would be ready to go as well. It could also include and call on libwdi for driver installation. The only drawback is that if you add libwdi, the installer grows by about 5.5 MB => not so lightweight anymore. Producing such an installer is very low on my list of priorities at the moment, especially as we still don't have an official release or an official way of producing binary snapshots. But if someone wants to step in and do it, they're more than welcome. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-08-19 12:54:06
|
Xiaofan Chen wrote: >> On Thu, Aug 19, 2010 at 11:01 AM, Michael Plante >> <mic...@gm...> wrote: >> > Xiaofan Chen wrote: >> >>> This particular part may be a .Net problem or my problem. I was putting >> >>> the 32bit libusb-1.0.dll in the same directory of benchmarkcon.exe. Maybe >> >>> I should have put the 64bit one to see if that helps. I will check again. >> > >> > >> > Would any user ever have a 32bit libusb-1.0.dll on a 64-bit OS? If so, is >> > that going to need a suffix? >> >> Yes there are many 32bit applications even on 64bit OS. >> >> No need a suffix. 32bit DLLs are installed to windows\syswow64 directory. >> 64bit DLLs are installed to windows\system32 directory. In short, you're saying we should never see this problem in practice, even when people go against Pete's wishes and install DLLs systemwide? Or is this directory structure not enforced well? Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 12:59:35
|
On Thu, Aug 19, 2010 at 8:53 PM, Michael Plante <mic...@gm...> wrote: >>>> Would any user ever have a 32bit libusb-1.0.dll on a 64-bit OS? >>>> If so, is that going to need a suffix? >>> >>> Yes there are many 32bit applications even on 64bit OS. >>> >>> No need a suffix. 32bit DLLs are installed to windows\syswow64 directory. >>> 64bit DLLs are installed to windows\system32 directory. > > In short, you're saying we should never see this problem in practice, even > when people go against Pete's wishes and install DLLs system wide? > Or is this directory structure not enforced well? If there is no official binary installer, the dlls may not be put in the correct directory. That is one reason I am in favor of an official installer. Of course, an wiki entry may help. But an installer would probably be easier to control. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-19 13:08:03
|
On 2010.08.19 13:59, Xiaofan Chen wrote: > On Thu, Aug 19, 2010 at 8:53 PM, Michael Plante > <mic...@gm...> wrote: >> In short, you're saying we should never see this problem in practice, even >> when people go against Pete's wishes and install DLLs system wide? >> Or is this directory structure not enforced well? > > If there is no official binary installer, the dlls may not be put in the correct > directory. That is one reason I am in favor of an official installer. > > Of course, an wiki entry may help. But an installer would probably > be easier to control. Yup. But then again, everybody should know that, on a 64 bit system, only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. How could anyone miss that? Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 13:41:08
|
On Thu, Aug 19, 2010 at 9:07 PM, Pete Batard <pb...@gm...> wrote: > > Yup. But then again, everybody should know that, on a 64 bit system, > only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. > How could anyone miss that? People just start to use 64bit Windows? You are probably a bit more optimistic whereas I am a bit more pessimistic in this point. :-) -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-08-19 13:46:22
|
Xiaofan Chen wrote: >> On Thu, Aug 19, 2010 at 9:07 PM, Pete Batard <pb...@gm...> wrote: >> > >> > Yup. But then again, everybody should know that, on a 64 bit system, >> > only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. >> > How could anyone miss that? >> >> People just start to use 64bit Windows? You are probably a bit >> more optimistic whereas I am a bit more pessimistic in this point. :-) I took it as sarcasm. But maybe a smiley would've helped. Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 13:50:58
|
On Thu, Aug 19, 2010 at 9:45 PM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> On Thu, Aug 19, 2010 at 9:07 PM, Pete Batard <pb...@gm...> wrote: >>> > Yup. But then again, everybody should know that, on a 64 bit system, >>> > only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. >>> > How could anyone miss that? >>> >>> People just start to use 64bit Windows? You are probably a bit >>> more optimistic whereas I am a bit more pessimistic in this point. :-) > > > I took it as sarcasm. But maybe a smiley would've helped. Hmm, sorry but I have put a smiley there. I am not so sure what you mean here. I was answering Pete's question. -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-08-19 14:27:48
|
>> On Thu, Aug 19, 2010 at 9:45 PM, Michael Plante >> <mic...@gm...> wrote: >> > Xiaofan Chen wrote: >> >>> On Thu, Aug 19, 2010 at 9:07 PM, Pete Batard <pb...@gm...> wrote: >> >>> > Yup. But then again, everybody should know that, on a 64 bit system, >> >>> > only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. >> >>> > How could anyone miss that? >> >>> >> >>> People just start to use 64bit Windows? You are probably a bit >> >>> more optimistic whereas I am a bit more pessimistic in this point. :-) >> > >> > >> > I took it as sarcasm. But maybe a smiley would've helped. >> >> Hmm, sorry but I have put a smiley there. I am not so sure >> what you mean here. I was answering Pete's question. Xiaofan, I.e., I thought Pete was joking, but wasn't sure. You were being straightforward. But nevermind. That part doesn't matter. Regards, Michael |
|
From: Pete B. <pb...@gm...> - 2010-08-19 14:41:31
|
On 2010.08.19 14:50, Xiaofan Chen wrote: > On Thu, Aug 19, 2010 at 9:45 PM, Michael Plante > <mic...@gm...> wrote: >> Xiaofan Chen wrote: >>>> On Thu, Aug 19, 2010 at 9:07 PM, Pete Batard<pb...@gm...> wrote: >>>>> Yup. But then again, everybody should know that, on a 64 bit system, >>>>> only 64 bit DLLs go in system32, and that 32 bit ones go into SysWOW64. >>>>> How could anyone miss that? >>>> >>>> People just start to use 64bit Windows? You are probably a bit >>>> more optimistic whereas I am a bit more pessimistic in this point. :-) >> >> >> I took it as sarcasm. But maybe a smiley would've helped. > > Hmm, sorry but I have put a smiley there. I am not so sure > what you mean here. I was answering Pete's question. Sorry about that. My remark about 32 into 64 and 64 into 32 being obvious was sarcasm. Should have put a smiley. Still very much puzzled about what was so impossible with using System64 for 64 bit DLLs, especially as System32 came from keeping system for 16 bit and placing 32 bit DLLs elsewhere... Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-08-19 15:43:42
|
pbr299 now released, including full filter driver support (upper + lower + multiple filter drivers). Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 23:52:34
|
On Thu, Aug 19, 2010 at 11:43 PM, Pete Batard <pb...@gm...> wrote:
> pbr299 now released, including full filter driver support (upper + lower
> + multiple filter drivers).
Not so sure how to test this. Now that Travis' inf file works to add
WinUSB as the lower filter to libusb0.sys (function driver).
I am not so sure if it makes sense to add winusb.sys as the
upper filter to libusb0.sys (function driver).
With winusb.sys as lower filter, it seems to work.
libusb-win32 test program can find the device. And the test
libusb-1.0 program also works.
DLL version: 1.2.1.17
Driver version: 1.2.1.17
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0001--0x1234-0x0001 1234/0001
- Manufacturer : Travis Robinson
- Product : Benchmark Device
- Serial Number: BMD001
wTotalLength: 32
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: c0h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 0
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 01h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 81h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
D:\work\libusb1win32\Test>lsusb-with-open.exe
1d6b:0001 (bus 0, device 255)
046d:c058 (bus 0, device 1)
1234:0001 (bus 0, device 2)
Found device 1234:0001 opened successfully!
1d6b:0002 (bus 1, device 255)
13d3:5130 (bus 1, device 1)
1d6b:0001 (bus 2, device 255)
0b05:1788 (bus 2, device 1)
1d6b:0002 (bus 3, device 255)
With winusb.sys as upper filter, it does not seem to
work. I just change one line of the inf file.
[Dev_AddReg]
HKR,,"DeviceInterfaceGUIDs",0x00010000,%Device_Guid%
HKR,,"UpperFilters",0x00010000,"WinUsb"
libusb-win32 test program can not find the device. And the test
libusb-1.0 program also does not work.
DLL version: 1.2.1.17
Driver version: -1.-1.-1.-1
bus/device idVendor/idProduct
D:\work\libusb1win32\Test>lsusb-with-open.exe
1d6b:0001 (bus 0, device 255)
046d:c058 (bus 0, device 1)
1234:0001 (bus 0, device 3)
-12:Operation not supported or unimplemented on this platform
failed opening device 1234:0001
--
Xiaofan
|
|
From: Pete B. <pb...@gm...> - 2010-08-20 00:00:32
|
On 2010.08.20 00:52, Xiaofan Chen wrote: > With winusb.sys as upper filter, it does not seem to > work. Can you get some debug libusb output? A simple run of xusb -d with any VID:PID will do (you can use the ones from the binary snapshot for that). Just trying to find out if we are at least able to detect the upper filter drivers, and there's some debug output about that during enum. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-08-20 11:36:58
|
I just ran a test with xusb and BenchmarkCon after switching Lower to
Upper in the inf, and I'm not seeing any problem on my system (Win7
x64). Here's the relevant excerpt from debug indicating that libusb
properly identifies the upper filter as the interface to use:
libusb:debug [set_device_paths] path (5:2):
\\.\USB#VID_04D8&PID_0053#LUDN0000#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): LIBUSB0
libusb:debug [set_device_paths] upper filter driver(s): WINUSB
libusb:debug [set_device_paths] matched upper filter driver name against
WinUSB API
Regards,
/Pete
|
|
From: Xiaofan C. <xia...@gm...> - 2010-08-20 12:25:52
|
On Fri, Aug 20, 2010 at 7:37 PM, Pete Batard <pb...@gm...> wrote:
> I just ran a test with xusb and BenchmarkCon after switching Lower to
> Upper in the inf, and I'm not seeing any problem on my system (Win7
> x64). Here's the relevant excerpt from debug indicating that libusb
> properly identifies the upper filter as the interface to use:
>
> libusb:debug [set_device_paths] path (5:2):
> \\.\USB#VID_04D8&PID_0053#LUDN0000#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
> libusb:debug [set_device_paths] driver(s): LIBUSB0
> libusb:debug [set_device_paths] upper filter driver(s): WINUSB
> libusb:debug [set_device_paths] matched upper filter driver name against
> WinUSB API
Just did a test under Windows 7 x32, yes libusb-1.0 seems to work.
But libusb-win32 will not work. I kind of expect this actually. It does
not seems to make much sense to use WinUSB as the upper filter
for libusb0.sys. On the other hand, there seems to be some problems
for libusb-win32 code about filter driver detection. We will look into it.
D:\work\libusb1\Test>lsusb-with-open.exe
1d6b:0002 (bus 0, device 255)
0403:cff8 (bus 0, device 1)
1d6b:0001 (bus 1, device 255)
058f:9360 (bus 1, device 1)
046d:c054 (bus 1, device 2)
1234:0001 (bus 1, device 3)
benchmark device 1234:0001 opened successfully!
Part of the log for "xusb -d"
libusb:debug [set_device_paths] path (1:3): \\.\USB#VID_1234&PID_0001#BMD001#{A5
DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): LIBUSB0
libusb:debug [set_device_paths] upper filter driver(s): WINUSB
libusb:debug [set_device_paths] matched upper filter driver name against WinUSB
API
Testlibusb-win32.exe output
DLL version: 1.2.1.17
Driver version: -1.-1.-1.-1
bus/device idVendor/idProduct
DebugView Log:
[3704] libusb0-dll:nfo [set_debug] setting debugging level to 4 (on)
[3704] libusb0-dll:err [set_debug] setting debug level failed
[3704] libusb0-dll:nfo [os_init] dll version: 1.2.1.17
[3704] libusb0-dll:err [os_init] getting driver version failed
[3704] libusb0-dll:nfo [os_find_busses] found bus-0
[3704] libusb0-dll:err [os_find_devices] couldn't read device descriptor
Reset device log:
libusb0-sys:nfo [dispatch_pnp] IRP_MN_SURPRISE_REMOVAL: is-filter=Y
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:nfo [dispatch_pnp] IRP_MN_REMOVE_DEVICE: is-filter=Y
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:nfo [dispatch_pnp] deleting device #1 usb\vid_1234&pid_0001&rev_0001
libusb0-sys:nfo [unload] [unloading-driver] v1.2.1.17
libusb0-sys:nfo [DriverEntry] [loading-driver] v1.2.1.17
libusb0-sys:dbg [debug_show_devices] [AttachedDevice #0] \Driver\usbhub
libusb0-sys:nfo [add_device] device #1 created for
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:wrn [add_device] [FILTER-MODE-MISMATCH] device is
reporting itself as filter when there are no attached device(s).
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:dbg [add_device] [filter-mode] id=#1 usb\vid_1234&pid_0001&rev_0001
libusb0-sys:nfo [add_device] complete status=00000000
libusb0-sys:nfo [dispatch_pnp] IRP_MN_START_DEVICE: is-filter=Y
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:dbg [on_start_complete] is-filter=Y usb\vid_1234&pid_0001&rev_0001
libusb0-sys:dbg [dispatch_pnp] IRP_MN_QUERY_CAPABILITIES: is-filter=Y
usb\vid_1234&pid_0001&rev_0001
libusb0-sys:dbg [dispatch_pnp] IRP_MN_QUERY_CAPABILITIES: is-filter=Y
usb\vid_1234&pid_0001&rev_0001
--
Xiaofan
|
|
From: Xiaofan C. <xia...@gm...> - 2010-08-20 14:59:23
|
On Fri, Aug 20, 2010 at 8:25 PM, Xiaofan Chen <xia...@gm...> wrote:
> On Fri, Aug 20, 2010 at 7:37 PM, Pete Batard <pb...@gm...> wrote:
>> I just ran a test with xusb and BenchmarkCon after switching Lower to
>> Upper in the inf, and I'm not seeing any problem on my system (Win7
>> x64). Here's the relevant excerpt from debug indicating that libusb
>> properly identifies the upper filter as the interface to use:
>>
>> libusb:debug [set_device_paths] path (5:2):
>> \\.\USB#VID_04D8&PID_0053#LUDN0000#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
>> libusb:debug [set_device_paths] driver(s): LIBUSB0
>> libusb:debug [set_device_paths] upper filter driver(s): WINUSB
>> libusb:debug [set_device_paths] matched upper filter driver name against
>> WinUSB API
>
> Just did a test under Windows 7 x32, yes libusb-1.0 seems to work.
> But libusb-win32 will not work. I kind of expect this actually. It does
> not seems to make much sense to use WinUSB as the upper filter
> for libusb0.sys. On the other hand, there seems to be some problems
> for libusb-win32 code about filter driver detection. We will look into it.
Under Windows 7 64bit, I got similar results. libusb-win32 does
not like WinUSB as the upper filter whereas libusb-1.0 seems
to work.
"xusb -d" works. The simple test program initially did not work.
Again I needed to compile it again (with MinGW) so that it works again.
This is very strange. I have no ideas why this happens.
I can only suspect there is some compatibility issues with
the binary snapshots and my MinGW.org 32bit compiler.
--
Xiaofan
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X