Menu
▾
▴
libusb-devel
|
From: Xiaofan C. <xia...@gm...> - 2010-08-17 23:54:13
|
On Mon, Aug 16, 2010 at 8:38 PM, Xiaofan Chen <xia...@gm...> wrote: >>> 1) How to install WinUSB as a filter driver? >>> http://msdn.microsoft.com/en-us/library/ff540207%28v=VS.85%29.aspx >>> "Winusb.sys is a kernel-mode driver that can be installed as either a filter or >>> function driver, above the protocol drivers in a USB device's kernel-mode >>> device stack." >>> >> >> I'm not sure this is possible. When you use UMDF, WinUSB gets installed >> as an upper filter to the UMDF proxy driver, and I THINK that's what >> they're trying to say here. However, Doron Holan of the Microsoft DDK >> team has stated that WinUSB cannot act as a general filter driver. >> Doron is usually right. >> >> However, it's easy enough to try this. You would install it like any >> other filter driver. Create a Services entry for it, then add the >> service name to the UpperFilters or LowerFilters (which is more likely) >> registry entry of the device you want to filter. It's actually easier >> than installing a full driver, because you don't need an INF. > > It is indeed possible. > > Travis has an inf file now install libusb-win32 device driver > (libusb0.sys) as the function driver and use WinUSB as the > lower filter driver. > > The following section adds WinUSB as the lower filter. > > [Dev_AddReg] > HKR,,"DeviceInterfaceGUIDs",0x00010000,%Device_Guid% > HKR,,"LowerFilters",0x00010000,"WinUsb" > > Test using the benchmark firmware and libusbdotnet benchmark > console program shows that this is indeed working. > http://libusbdotnet.svn.sourceforge.net/viewvc/libusbdotnet/trunk/stage/ In this case, there is a problem for libusb-1.0 Windows backend. According to Travis, this may well be due to the way libusb-1.0 Windows backend gets the driver string -- using SPDRP_SERVICE (for WinUSB) or ClassGUID (for HID). // In case we can't read the driver string through SPDRP_SERVICE (which is // the case for HID), we need the ClassGUID for comparison. if(!SetupDiGetDeviceRegistryPropertyW(dev_info, &dev_info_data, SPDRP_CLASSGUID, NULL, (BYTE*)guid_string_w, sizeof(guid_string_w), &size)) { usbi_warn(ctx, "could not read class GUID for device %s, skipping: %s", dev_interface_details->DevicePath, windows_error_str(0)); continue; } CLSIDFromString(guid_string_w, &class_guid); // Attempt to read the driver string if(!SetupDiGetDeviceRegistryProperty(dev_info, &dev_info_data, SPDRP_SERVICE, NULL, (BYTE*)driver, MAX_KEY_LENGTH, &size)) { driver[0] = 0; } Inf file for Microchip libusb demo firmware (can be easily changed to other device). ; libusb-win32 inf file with WinUSB as lower filter ; Copyright (c) 2010 LibUsbDotNet(GNU LGPL) ;-------------------------------------------------------------------------- ; WinUSB & libusb-win32 (Strings) ;-------------------------------------------------------------------------- [Strings] DeviceName = "MCHPUSB LIBUSB DEMO Device with libusb-win32 and winusb" VendorName = "Travis Robinson" DeviceID = "VID_04d8&PID_0204" Device_Guid = "{5c8d08f5-c14c-4cfb-8e42-0fa18427df54}" WinUsb_SourceName = "WinUSB Device Install Disk" LibUsb_SourceName = "libusb-win32 Device Install Disk" WinUsb_SvcDisplay = "WinUSB - Kernel Driver 08/14/2010 1.0.0.0" LibUsb_SvcDisplay = "libusb-win32 - Kernel Driver 08/14/2010 1.0.0.0" ;-------------------------------------------------------------------------- ; WinUSB & libusb-win32 (Version / ClassInstall32 / Manufacturer) ;-------------------------------------------------------------------------- [Version] Signature = "$Windows NT$" Class = "LibWinUsb Devices" ClassGuid = {83BDC82B-3D81-4b65-9F90-4AEEC93BE866} Provider = %VendorName% CatalogFile = Benchmark_Device_LibWinUsb.cat DriverVer = 08/14/2010, 1.0.0.0 [ClassInstall32] Addreg = libusb_class_install_add_reg [libusb_class_install_add_reg] HKR,,,0,"LibWinUsb Devices" HKR,,Icon,,-20 [Manufacturer] %VendorName% = Devices, NT, NTAMD64, NTIA64 ;-------------------------------------------------------------------------- ; libusb-win32 & WinUSB (install) ;-------------------------------------------------------------------------- [USB_Install.NT] Include = winusb.inf Needs = WINUSB.NT CopyFiles = libusb_files_sys, libusb_files_dll_x86 [USB_Install.NTAMD64] Include = winusb.inf Needs = WINUSB.NT CopyFiles = libusb_files_sys, libusb_files_dll, libusb_files_dll_wow64 [USB_Install.NTIA64] Include = winusb.inf Needs = WINUSB.NT CopyFiles = libusb_files_sys, libusb_files_dll, libusb_files_dll_wow64 ;-------------------------------------------------------------------------- ; libusb-win32 & WinUSB (install service) ;-------------------------------------------------------------------------- [USB_Install.NT.Services] Include = winusb.inf AddService = WinUSB, 0x00000000, winusb_add_service AddService = libusb0, 0x00000002, libusb_add_service [USB_Install.NTAMD64.Services] Include = winusb.inf AddService = WinUSB, 0x00000000, winusb_add_service AddService = libusb0, 0x00000002, libusb_add_service [USB_Install.NTIA64.Services] Include = winusb.inf AddService = WinUSB, 0x00000000, winusb_add_service AddService = libusb0, 0x00000002, libusb_add_service ;-------------------------------------------------------------------------- ; WinUSB service ;-------------------------------------------------------------------------- [winusb_add_service] DisplayName = %WinUsb_SvcDisplay% ServiceType = 1 StartType = 3 ErrorControl = 1 ServiceBinary = %12%\WinUSB.sys ;-------------------------------------------------------------------------- ; libusb-win32 service ;-------------------------------------------------------------------------- [libusb_add_service] DisplayName = %LibUsb_SvcDisplay% ServiceType = 1 StartType = 3 ErrorControl = 0 ServiceBinary = %12%\libusb0.sys ;-------------------------------------------------------------------------- ; WinUSB specific (install,co-installer) ;-------------------------------------------------------------------------- [USB_Install.NT.Wdf] KmdfService = WINUSB, WinUsb_Install [USB_Install.NTAMD64.Wdf] KmdfService = WINUSB, WinUsb_Install [USB_Install.NTIA64.Wdf] KmdfService = WINUSB, WinUsb_Install [WinUSB_Install] KmdfLibraryVersion = 1.9 [USB_Install.NT.CoInstallers] AddReg = CoInstallers_AddReg CopyFiles = CoInstallers_CopyFiles [USB_Install.NTAMD64.CoInstallers] AddReg = CoInstallers_AddReg CopyFiles = CoInstallers_CopyFiles [USB_Install.NTIA64.CoInstallers] AddReg = CoInstallers_AddReg CopyFiles = CoInstallers_CopyFiles [CoInstallers_AddReg] HKR,,CoInstallers32,0x00010000,"WdfCoInstaller01009.dll,WdfCoInstaller","WinUSBCoInstaller2.dll" [CoInstallers_CopyFiles] WinUSBCoInstaller2.dll WdfCoInstaller01009.dll ;-------------------------------------------------------------------------- ; WinUSB & libusb-win32 (HW AddReg,DelReg) ;-------------------------------------------------------------------------- [USB_Install.NT.HW] AddReg = Dev_AddReg DelReg = Dev_DelReg [USB_Install.NTAMD64.HW] AddReg = Dev_AddReg DelReg = Dev_DelReg [USB_Install.NTIA64.HW] AddReg = Dev_AddReg DelReg = Dev_DelReg [Dev_DelReg] HKR,,LowerFilters HKR,,UpperFilters HKR,,SurpriseRemovalOK HKR,,DeviceInterfaceGUIDs [Dev_AddReg] HKR,,"DeviceInterfaceGUIDs",0x00010000,%Device_Guid% HKR,,"LowerFilters",0x00010000,"WinUsb" ;---------------------------------------------------------------------------- ; WinUSB & libusb-win32 ; DestinationDirs / file list sections / SourceDisksNames / SourceDisksFiles ;---------------------------------------------------------------------------- [DestinationDirs] CoInstallers_CopyFiles = 11 libusb_files_sys = 10,system32\drivers libusb_files_dll = 10,system32 libusb_files_dll_wow64 = 10,syswow64 libusb_files_dll_x86 = 10,system32 [libusb_files_sys] libusb0.sys [libusb_files_dll] libusb0.dll [libusb_files_dll_x86] libusb0.dll, libusb0_x86.dll [libusb_files_dll_wow64] libusb0.dll, libusb0_x86.dll [SourceDisksNames] 1 = %WinUsb_SourceName% 2 = %LibUsb_SourceName% [SourceDisksFiles.x86] WinUSBCoInstaller2.dll = 1,x86 WdfCoInstaller01009.dll = 1,x86 libusb0.sys = 2,x86 libusb0_x86.dll = 2,x86 [SourceDisksFiles.amd64] WinUSBCoInstaller2.dll = 1,amd64 WdfCoInstaller01009.dll = 1,amd64 libusb0.sys = 2,amd64 libusb0.dll = 2,amd64 libusb0_x86.dll = 2,x86 [SourceDisksFiles.ia64] WinUSBCoInstaller2.dll = 1,ia64 WdfCoInstaller01009.dll = 1,ia64 libusb0.sys = 2,ia64 libusb0.dll = 2,ia64 libusb0_x86.dll = 2,x86 ;-------------------------------------------------------------------------- ; WinUSB & libusb-win32 (models section) ;-------------------------------------------------------------------------- [Devices] %DeviceName% = USB_Install, USB\%DeviceID% [Devices.NT] %DeviceName% = USB_Install.NT, USB\%DeviceID% [Devices.NTAMD64] %DeviceName% = USB_Install.NTAMD64, USB\%DeviceID% [Devices.NTIA64] %DeviceName% = USB_Install.NTIA64, USB\%DeviceID% Test program from Travis, modified from lsusb.c. #include <stdio.h> #include <sys/types.h> #include <libusb.h> static void print_devs(libusb_device **devs) { libusb_device *dev; libusb_device_handle* dev_handle; int i = 0; while ((dev = devs[i++]) != NULL) { struct libusb_device_descriptor desc; int r = libusb_get_device_descriptor(dev, &desc); if (r < 0) { fprintf(stderr, "failed to get device descriptor"); return; } printf("%04x:%04x (bus %d, device %d)\n", desc.idVendor, desc.idProduct, libusb_get_bus_number(dev), libusb_get_device_address(dev)); // libusb-1.0 should be able to open this benchmark device because // WinUSB is installed as a lower filter driver. if (desc.idVendor == 0x04d8 && desc.idProduct == 0x0204) { r = libusb_open(dev,&dev_handle); if (r < 0) { fprintf(stderr, "%d:%s\nfailed opening device %04x:%04x\n", r, libusb_strerror(r), desc.idVendor, desc.idProduct); break; } else { printf("Found device %04x:%04x opened successfully!\n", desc.idVendor, desc.idProduct); } libusb_close(dev_handle); } } } int main(void) { libusb_device **devs; int r; ssize_t cnt; r = libusb_init(NULL); if (r < 0) return r; cnt = libusb_get_device_list(NULL, &devs); if (cnt < 0) return (int) cnt; print_devs(devs); libusb_free_device_list(devs, 1); libusb_exit(NULL); return 0; } mcuee@WIN7HOMEX64_PC /d/work/libusb1win32/Test $ gcc -o libusb-with-open lsusb-with-open.c -lusb-1.0 -lsetupapi -lole32 mcuee@WIN7HOMEX64_PC /d/work/libusb1win32/Test $ libusb-with-open 1d6b:0001 (bus 0, device 255) 046d:c058 (bus 0, device 1) 04d8:0204 (bus 0, device 3) -12:Operation not supported or unimplemented on this platform failed opening device 04d8:0204 -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-08-18 00:21:17
|
On 2010.08.18 00:54, Xiaofan Chen wrote: > mcuee@WIN7HOMEX64_PC /d/work/libusb1win32/Test > $ libusb-with-open > 1d6b:0001 (bus 0, device 255) > 046d:c058 (bus 0, device 1) > 04d8:0204 (bus 0, device 3) > -12:Operation not supported or unimplemented on this platform > failed opening device 04d8:0204 Do you have the debug output on that? Can you confirm that it actually chokes on "could not read class GUID for device"? As indicated from the comments, if all you're doing is test with WinUSB, you should be able to comment the SetupDiGetDeviceRegistryPropertyW(dev_info, &dev_info_data, SPDRP_CLASSGUID, section for testing. What happens when it's commented out? Regards, /Pete |
|
From: Travis <tra...@co...> - 2010-08-18 07:37:15
|
>> -12:Operation not supported or unimplemented on this platform >> failed opening device 04d8:0204 > > Do you have the debug output on that? WinXP SP3 (32 bit) pbr297 Here is the output: http://libusbdotnet.sourceforge.net/no_remove/libusb10/lsusb-with-open-stdout.log http://libusbdotnet.sourceforge.net/no_remove/libusb10/lsusb-with-open-stderr.log Here is the inf we are using: http://libusbdotnet.sourceforge.net/no_remove/libusb10/Benchmark_Device_LibWinUsb.inf This installs the device as libusb-win32 with winusb as a lower filter. It works with the WinUSB GetDeviceHandle() method here: http://msdn.microsoft.com/en-us/library/ff540174%28VS.85%29.aspx as well as libusbodtnet (provided the driver=libusb10 option is not used;) > Can you confirm that it actually chokes on "could not read class GUID > for device"? As indicated from the comments, if all you're doing is test > with WinUSB, you should be able to comment the > SetupDiGetDeviceRegistryPropertyW(dev_info, &dev_info_data, > SPDRP_CLASSGUID, section for testing. What happens when it's commented > out? I set a breakpoint here (line 1214) and it doesn't get this far. I think the problem comes sooner, maybe in set_device_paths()? Regards, Travis |
|
From: Pete B. <pb...@gm...> - 2010-08-18 12:32:08
|
On 2010.08.18 08:37, Travis wrote: > http://libusbdotnet.sourceforge.net/no_remove/libusb10/lsusb-with-open-stderr.log Obviously the "libusb:debug [initialize_device] * DRIVERLESS DEVICE *" line seems to apply to the device you are trying to access and if libusb sees it as driverless, you won't be able to open it. I'm also worried about the following: libusb:error [cache_config_descriptors] could not access configuration descriptor (actual): [170] The requested resource is in use. Wondering if using filter drivers could lead to access issues... Now there's some chance that I can review the driverless device detection of libusb according to what libwdi does, as I'm doing device enumeration and driver detection a bit differently there. If Zadig or inf-wizard return the expected driver for your device, I should be able to fix libusb to do the same. > Here is the inf we are using: > http://libusbdotnet.sourceforge.net/no_remove/libusb10/Benchmark_Device_LibWinUsb.inf > This installs the device as libusb-win32 with winusb as a lower filter. I think I'll give it a try, to see if I can reproduce and address the issue. > It works with the WinUSB GetDeviceHandle() method here: > http://msdn.microsoft.com/en-us/library/ff540174%28VS.85%29.aspx > as well as libusbodtnet (provided the driver=libusb10 option is not used;) Yeah. The problem I have with Microsoft's samples is that they all require that you have the DeviceInterface GUID beforehand. Retrieving that GUID in a generic fashion on the other hand, can be quite tricky. Regards, /Pete |
|
From: Peter S. <pe...@st...> - 2010-08-18 13:19:52
|
Pete Batard wrote: > Obviously the "libusb:debug [initialize_device] * DRIVERLESS DEVICE *" > line seems to apply to the device you are trying to access and if libusb > sees it as driverless, you won't be able to open it. As a side note, *PLEASE* let's change this message to very clearly indicate that this condition is a problem. Remember that "driverless" is considered quite desireable by many, and to avoid confusion we should not be using that exact word. I suggest something like: "Device has no driver, access will not be possible!" //Peter |
|
From: Peter S. <pe...@st...> - 2010-08-18 13:44:01
|
Pete Batard wrote: > > "Device has no driver, access will not be possible!" > > Sure, but without the exclamation point, as this is a perfectly > acceptable situation and not an indication of an error in any way. It's an error if I want to access that device, right? Anyway, neither exclamtion point nor exact wording are so important as long as driverless is not in the message. :) //Peter |
|
From: Peter S. <pe...@st...> - 2010-08-18 14:11:41
|
Pete Batard wrote: > > It's an error if I want to access that device, right? > > Not really. It will generate an error on open, but you're supposed to > only access devices for which you have a supported libusb 1.0 driver > installed, so I'd say it's a mistake (from the app developer) rather > than an error. Wow, really surprising terminology, but maybe you'll agree that it is an exception to the normal working case, if the intention is to access the device. We should try to avoid that something which is an exception might be interpreted as something positive. > But how exactly is using "driverless" in that situation confusing? The point is that you can not rely on context to add meaning to the word driverless, because some (most, I guess) libusb users may not know about that context and will go "sweet, my device is driverless, that's perfect, that's what I want" since they know that libusb can be used to communicate with devices without needing to develop a device driver. "Driverless" is a state, without information about expectations, and it already has a de-facto meaning of "driving a device without writing a device driver". If we re-use or re-purpose the term for anything else then we risk creating unneccessary confusion. //Peter |
|
From: Peter S. <pe...@st...> - 2010-08-18 16:48:22
|
Pete Batard wrote: > On 2010.08.18 15:11, Peter Stuge wrote: > > Wow, really surprising terminology, but maybe you'll agree that it is > > an exception to the normal working case, if the intention is to > > access the device. We should try to avoid that something which is an > > exception might be interpreted as something positive. > > This is Windows. Trying to access an USB device that doesn't have a > driver on Windows is about as ridiculous as trying to access an IEEE > 1394 device with libusb Yeah I know, and everyone else on the list knows it too, but anyone who hasn't dealt with device drivers before on Windows might not know. > use to list devices), and I were to output something like "* FIREWIRE > DEVICE *" everytime I had to ignore a 1394 during enum (because it's > debug, and I'm free to output whatever I want in debug), you wouldn't > come complain that people are going to expect to access their FireWire > devices because there's a *DEBUG* message about them during enum. > > Well, it's exactly the same with driverless. Except that "FIREWIRE" is a term primarily associated with another domain, while "driverless" already has meaning in the USB domain. > But of course, now I understand where you're coming from. Linux (and > possibly Darwin) users are expected to access "driverless" devices, Maybe you share my experience that many people who are starting out with USB device development consider how to make their device driverless, because it supposedly makes for a smoother end user experience, with less installation issues. The net has lots of HID examples which claim to offer this feature, and book authors bring it up too. I make sure to point out exactly these points you make, that there is *always* a driver involved, on every system. The question is which userspace APIs we can choose from as an application. > > "Driverless" is a state, without information about expectations, and > > it already has a de-facto meaning of "driving a device without > > writing a device driver". > > This is your (Linux) de-facto. Well, no. It's the de-facto from communication with people on mailing lists, at local interest groups, conferences, and presentations and workshops, who all know enough about USB to realize that HID means that no kernel driver needs to be written, but who haven't yet gotten a more complete view of things. > The Windows de-facto would be "device that cannot be accessed at > all". Your interpretation of "driverless" is technically correct of course, but as I've found it doesn't match that of typical libusb users. Since there's a possible mismatch, my point is that we should try to avoid the possible confusion. > Glad to see that you eventually rallied to seeing debug messages as > something that our users might want to work with), Not so much work with, but they might come across some, so yes, being very clear is a good thing. > but you can't simply barge in and assume that Windows people will > interpret things in the same manner as Linux people do. My de-facto > assumption on Windows is that, if anybody sees driverless, they'll > equate this with no device access ever. Unlike you I'm not assuming here. I've talked to a bunch of people about this, many times. I'm not making it up. //Peter |
|
From: Pete B. <pb...@gm...> - 2010-08-18 17:03:43
|
On 2010.08.18 17:48, Peter Stuge wrote:
> Since there's a possible mismatch, my point is that we should try to
> avoid the possible confusion.
And I agree with that. The original point about the original debug
message being subject to different interpretations is a very valid point.
But I consider that a message that uses the proper terminology
("driverless") while clarifying what this means in the scope of libusb
(which I agree is needed - there's almost an incentive to turn this into
a warning if we find that trying to access a driverless device eludes
users) would be fine, especially in a debug message. As such, something
like:
"Driverless device detected. You will not be able to access this device
in libusb"
doesn't strike me as much of a contention point.
If anything, we might as well educate people as to the proper use of
driverless...
Regards,
/Pete
|
|
From: Xiaofan C. <xia...@gm...> - 2010-08-18 13:05:10
|
On Wed, Aug 18, 2010 at 8:21 AM, Pete Batard <pb...@gm...> wrote:
> On 2010.08.18 00:54, Xiaofan Chen wrote:
>> mcuee@WIN7HOMEX64_PC /d/work/libusb1win32/Test
>> $ libusb-with-open
>> 1d6b:0001 (bus 0, device 255)
>> 046d:c058 (bus 0, device 1)
>> 04d8:0204 (bus 0, device 3)
>> -12:Operation not supported or unimplemented on this platform
>> failed opening device 04d8:0204
>
> Do you have the debug output on that?
Interestingly I have different results for two device.
(Tested under Windows 7 x86 32bit)
First case:
Benchmark Device (USB Composite) Interface 0.
(Interface 1 is using pure libusb-win32 device driver)
In this case it is working.
Device: 04d2:0001 Interface 0.
1d6b:0002 (bus 0, device 255)
1d6b:0001 (bus 1, device 255)
058f:9360 (bus 1, device 1)
046d:c054 (bus 1, device 2)
04d2:0001 (bus 1, device 3)
benchmark device 04d2:0001 opened successfully!
04d8:0204 (bus 1, device 4)
libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation
libusb:debug [windows_clock_gettime_threaded] hires timer available
(Frequency: 2539042 Hz)
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [libusb_get_device_list]
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255
libusb:debug [usb_enumerate_hub] allocating new device for session 255
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB20#4&7056C45&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511
libusb:debug [usb_enumerate_hub] allocating new device for session 511
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB#4&278C294E&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257
libusb:debug [usb_enumerate_hub] allocating new device for session 257
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 2 session_id 258
libusb:debug [usb_enumerate_hub] allocating new device for session 258
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 34 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 3 session_id 259
libusb:debug [usb_enumerate_hub] allocating new device for session 259
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 55 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 4 session_id 260
libusb:debug [usb_enumerate_hub] allocating new device for session 260
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [set_device_paths] path (1:2):
\\.\USB#VID_046D&PID_C054#5&207B166D&0&4#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: HidUsb
libusb:debug [set_hid_device] interface_path[0]:
\\.\HID#VID_046D&PID_C054#6&A6CCB04&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (1:3):
\\.\USB#VID_04D2&PID_0001#BMD002#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: usbccgp
libusb:warning [set_composite_device] interface_path[0]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] interface_path[1]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] composite device: no interfaces were found
libusb:debug [set_device_paths] path (1:4):
\\.\USB#VID_04D8&PID_0204#5&207B166D&0&8#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
libusb:debug [set_device_paths] path (1:1):
\\.\USB#VID_058F&PID_9360#2004888#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: USBSTOR
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_open] open 1.3
libusb:debug [libusb_close]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_unref_device] destroy device 0.255
libusb:debug [libusb_unref_device] destroy device 1.255
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 1.2
libusb:debug [libusb_unref_device] destroy device 1.3
libusb:debug [libusb_unref_device] destroy device 1.4
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context
libusb:debug [usbi_remove_pollfd] remove fd 3
libusb:debug [windows_clock_gettime_threaded] timer thread quitting
Second case:
Microchip libusb firmware demo device (Single interface).
In this case it is not working.
Device: 04d8:0204
libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation
libusb:debug [windows_clock_gettime_threaded] hires timer available
(Frequency: 2539042 Hz)
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [libusb_get_device_list]
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255
libusb:debug [usb_enumerate_hub] allocating new device for session 255
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB20#4&7056C45&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511
libusb:debug [usb_enumerate_hub] allocating new device for session 511
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB#4&278C294E&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257
libusb:debug [usb_enumerate_hub] allocating new device for session 257
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 2 session_id 258
libusb:debug [usb_enumerate_hub] allocating new device for session 258
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 34 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 3 session_id 259
libusb:debug [usb_enumerate_hub] allocating new device for session 259
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 55 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 4 session_id 260
libusb:debug [usb_enumerate_hub] allocating new device for session 260
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [set_device_paths] path (1:2):
\\.\USB#VID_046D&PID_C054#5&207B166D&0&4#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: HidUsb
libusb:debug [set_hid_device] interface_path[0]:
\\.\HID#VID_046D&PID_C054#6&A6CCB04&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (1:3):
\\.\USB#VID_04D2&PID_0001#BMD002#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: usbccgp
libusb:warning [set_composite_device] interface_path[0]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] interface_path[1]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] composite device: no interfaces were found
libusb:debug [set_device_paths] path (1:4):
\\.\USB#VID_04D8&PID_0204#5&207B166D&0&8#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
libusb:debug [set_device_paths] path (1:1):
\\.\USB#VID_058F&PID_9360#2004888#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: USBSTOR
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_open] open 1.4
libusb:debug [unsupported_open] unsupported API call for 'open'
(unrecognized device driver)
-12:Operation not supported or unimplemented on this platform
failed opening device 04d8:0204
libusb:debug [libusb_unref_device] destroy device 0.255
libusb:debug [libusb_unref_device] destroy device 1.255
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 1.2
libusb:debug [libusb_unref_device] destroy device 1.3
libusb:debug [libusb_unref_device] destroy device 1.4
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context
libusb:debug [1d6b:0002 (bus 0, device 255)
1d6b:0001 (bus 1, device 255)
058f:9360 (bus 1, device 1)
046d:c054 (bus 1, device 2)
04d2:0001 (bus 1, device 3)
04d8:0204 (bus 1, device 4)
usbi_remove_pollfd] remove fd 3
libusb:debug [windows_clock_gettime_threaded] timer thread quitting
--
Xiaofan
|
|
From: Pete B. <pb...@gm...> - 2010-08-18 13:33:11
|
On 2010.08.18 14:04, Xiaofan Chen wrote:
> In this case it is working.
> Device: 04d2:0001 Interface 0.
> \\.\USB#VID_04D2&PID_0001#BMD002#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
> libusb:debug [set_device_paths] driver: usbccgp
> libusb:warning [set_composite_device] interface_path[0]: unhandled API
> - interface will be disabled
Weird. If the interface is disabled, you shouldn't be able to access it
at all with libusb 1.0
> In this case it is not working.
> Device: 04d8:0204
> \\.\USB#VID_04D8&PID_0204#5&207B166D&0&8#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
> libusb:debug [set_device_paths] driver: libusb0
If the driver is identified as libusb0, then it wouldn't be supported
either.
The current libusb 1.0 very much relies on the driver string or driver
class GUID to find out if the driver is supported. Only if the
driver/driver class is seen as WinUSB or HID will libusb 1.0 support it.
If the debug output above, it looks to me like the driver/GUID we get is
the one from libusb0.sys, rather than WinUSB. Now, of course, another
way would be to assume the driver is supported regardless (masquerading
is something I really anticipated) and try to open the device with each
of the API we support, but this could be a very disruptive process, and
I also have doubts about how we would handle a composite parent with a
filter driver.
Is it possible that the only reason it works in libusbdotnet is because
you are explicitly telling the kind of driver you expect (WinUSB) so you
bypass driver detection altogether?
Still need to look at it further, so maybe I'm way off, but not being
able to tell the kind of driver by simply using the regular APIs could
be an issue for libusb-1.0. If the issue is driver masquerading, do you
know if filter drivers provide additional calls that could help us find
out if a supported driver hides behind the regular one? Or possibly,
since you have control over the filter driver, could you implement an
IOCTL to report the additional drivers, that libusb 1.0 could use during
enumeration?
Regards,
/Pete
|
|
From: Pete B. <pb...@gm...> - 2010-08-18 13:38:55
|
On 2010.08.18 14:19, Peter Stuge wrote: > As a side note, *PLEASE* let's change this message to very clearly > indicate that this condition is a problem. I can do that, but I don't consider the message to indicate a problem either (else it wouldn't be debug). It's just a notification that a device on a system has (supposedly) been detected without a driver, which is a perfectly acceptable expectation and indeed desirable. So I'm not sure I see the point of modifying what is purely a debug message... In short, this message is usually NOT and indication of a problem. > "Device has no driver, access will not be possible!" Sure, but without the exclamation point, as this is a perfectly acceptable situation and not an indication of an error in any way. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-08-18 13:55:36
|
On 2010.08.18 14:43, Peter Stuge wrote: > It's an error if I want to access that device, right? Not really. It will generate an error on open, but you're supposed to only access devices for which you have a supported libusb 1.0 driver installed, so I'd say it's a mistake (from the app developer) rather than an error. > Anyway, neither exclamtion point nor exact wording are so important > as long as driverless is not in the message. :) OK. Still not following why using the driverless word is a NO_NO. I added asterisks and uppercase to try to make sure developers would be alerted of the potential issue of trying to access a device that had been detected without a driver by libusb, and I reckon that indicating exactly what's (not) to be expected from driverless devices will help clarify things But how exactly is using "driverless" in that situation confusing? Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-18 14:25:24
|
On Wed, Aug 18, 2010 at 9:33 PM, Pete Batard <pb...@gm...> wrote:
> If the debug output above, it looks to me like the driver/GUID we get is
> the one from libusb0.sys, rather than WinUSB.
Yes libusb0.sys is the function driver. WinUSB is the lower filter driver.
> Now, of course, another
> way would be to assume the driver is supported regardless (masquerading
> is something I really anticipated) and try to open the device with each
> of the API we support, but this could be a very disruptive process, and
Maybe this is not so common to use libusb0.sys as the function driver
and WinUSB as the lower filter driver.
On the other hand, it seems quite common for WinUSB as the
lower filter driver for UMDF device to handle Power and other stuff.
Not so sure what the solution will be.
>
> I also have doubts about how we would handle a composite parent with a
> filter driver.
>
It seems in this case, libusb-1.0 WinUSB backend will not be able to
find the device and will not report an error either.
Test case:
Benchmark firmware, USB composite device, dual Bulk interface.
libusb-win32 as the function driver for the parent device, WinUSB
as the lower filter driver.
libusbdotnet works with either WinUSB driver or libusb-win32
driver, but not libusb10 option.
The test lsusb-with-open program will fail then.
D:\work\libusb1\Test>lsusb-with-open.exe
libusb:debug [libusb_init] created default context
libusb:debug [libusb_init]
libusb:debug [init_polling] Will use CancelIoEx for I/O cancellation
libusb:debug [windows_clock_gettime_threaded] hires timer available (Frequency:
2539042 Hz)
libusb:debug [usbi_add_pollfd] add fd 3 events 1
libusb:debug [libusb_get_device_list]
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255
libusb:debug [usb_enumerate_hub] allocating new device for session 255
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\.\USB#ROOT_HUB20#4&7056C45&0#{F1
8A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511
libusb:debug [usb_enumerate_hub] allocating new device for session 511
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub: \\.\USB#ROOT_HUB#4&278C294E&0#{F18
A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257
libusb:debug [usb_enumerate_hub] allocating new device for session 257
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 3 session_id 259
libusb:debug [usb_enumerate_hub] allocating new device for session 259
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 34 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 6 session_id 262
libusb:debug [usb_enumerate_hub] allocating new device for session 262
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0 (bConfigurati
onValue=1, 55 bytes)
libusb:debug [set_device_paths] path (1:3): \\.\USB#VID_046D&PID_C054#5&207B166D
&0&4#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: HidUsb
libusb:debug [set_hid_device] interface_path[0]: \\.\HID#VID_046D&PID_C054#6&A6C
CB04&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (1:1): \\.\USB#VID_058F&PID_9360#2004888#{A
5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: USBSTOR
libusb:debug [set_device_paths] path (1:6): \\.\USB#VID_1234&PID_0001#BMD002#{A5
DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver: libusb0
libusb:debug [libusb_get_device_descriptor]
1d6b:0002 (bus 0, device 255)
libusb:debug [libusb_get_device_descriptor]
1d6b:0001 (bus 1, device 255)
libusb:debug [libusb_get_device_descriptor]
058f:9360 (bus 1, device 1)
libusb:debug [libusb_get_device_descriptor]
046d:c054 (bus 1, device 3)
libusb:debug [libusb_get_device_descriptor]
1234:0001 (bus 1, device 6)
libusb:debug [libusb_open] open 1.6
libusb:debug [unsupported_open] unsupported API call for 'open' (unrecognized de
vice driver)
-12:Operation not supported or unimplemented on this platform
failed opening device 1234:0001
libusb:debug [libusb_unref_device] destroy device 0.255
libusb:debug [libusb_unref_device] destroy device 1.255
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 1.3
libusb:debug [libusb_unref_device] destroy device 1.6
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context
libusb:debug [usbi_remove_pollfd] remove fd 3
libusb:debug [windows_clock_gettime_threaded] timer thread quitting
--
Xiaofan
|
|
From: Pete B. <pb...@gm...> - 2010-08-18 15:47:28
|
On 2010.08.18 15:25, Xiaofan Chen wrote: > Not so sure what the solution will be. One quick way would be add a special case for libusb0.sys => if we see libusb0 during enum, we assume there's a lower filter driver we might be able to support. Of course, as soon as we add libusb0 support or people use their own filter drivers, we'll be back to square one... Another solution would be to add a Windows specific call to force a specific backend to be used, and ignore the driver detected during enum. Hoping to have a chance to play with the filter driver later on, to see what we could do there Regards, /Pete |
|
From: Peter S. <pe...@st...> - 2010-08-18 16:50:16
|
Pete Batard wrote: > > Not so sure what the solution will be. > > One quick way would be add a special case for libusb0.sys => if we > see libusb0 during enum, we assume there's a lower filter driver we > might be able to support. But is that enough? Couldn't WinUSB be used as filter driver also underneath any other driver besides libusb0.sys? > Another solution would be to add a Windows specific call to force a > specific backend to be used, That doesn't sound so attractive. > and ignore the driver detected during enum. Is there no way to enumerate also filter drivers? //Peter |
|
From: Pete B. <pb...@gm...> - 2010-08-18 19:23:44
|
On 2010.08.18 17:50, Peter Stuge wrote: > Is there no way to enumerate also filter drivers? Having now had a chance to play with the filter driver device, it looks like there's a "Device lower filters" entry that is being added when a filter driver is used and which contains the service name (eg "WinUSB" of a libusb0.sys filter driver device). No idea what happens when there are multiple "Device lower filters" there (plural, so there could be more than one - space delimiter? semicolon?). If anybody knows, or has access to a device with multiple lower filters, feel free to enlighten us with what you see in the "Device lower filters" property. Now, it seems we should be able to use the SPDRP_LOWERFILTERS key [1] to retrieve that property, so I am planning to add a fallback to lower filter to the code shortly. This should work fine as simply adding libusb0 to the list of known WinUSB API names allowed me to access a "filtered" device on my machine successfully and the libusb-win32 filter driver inf seems to work fine on my platform as well. As to what we should do if both the filter driver and the regular driver are supported in our backend, right now my view would be to just ignore the filter driver always, unless we have specific scenario where we see being able to switch to lower filter as a must have. Otherwise we will need: - either a new API call for driver backend selection or the creation of a fake composite parent device (with one additional interface per filter driver, though that would be probably abuse the composite device definition, and we could end up with interfaces of composite devices being "composite devices" themselves) - code in most of the libusb API calls to prevent simultaneous access to the filtered and unfiltered device. All in all, supporting user switching between filtered and unfiltered looks like a lot of effort, as well as adding a lot of complexity, for benefit that I don't really see ATM. We might however tweak the fallback between regular and filter driver to try filter first, as I suspect that, if somebody added a filter, they probably prefer that driver to be used over regular where possible. In short, being able to use libusb as a filter driver for drivers which we don't currently support is a good thing, and should be straightforward enough to implement. On the other hand, being able to use libusb to switch between 2 drivers that we support looks like a more disputable feature to carry... Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ff551967%28VS.85%29.aspx |
|
From: Travis <tra...@co...> - 2010-08-18 20:01:28
|
> On 2010.08.18 17:50, Peter Stuge wrote: >> Is there no way to enumerate also filter drivers? > > Having now had a chance to play with the filter driver device, it looks > like there's a "Device lower filters" entry that is being added when a > filter driver is used and which contains the service name (eg "WinUSB" > of a libusb0.sys filter driver device). > No idea what happens when there are multiple "Device lower filters" > there (plural, so there could be more than one - space delimiter? > semicolon?). If anybody knows, or has access to a device with multiple > lower filters, feel free to enlighten us with what you see in the > "Device lower filters" property. LowerFilters and UpperFilters are REG_MULTI_SZ (String array). They are separated with a NULL and terminated with two (2) NULLS. IE: WinUSB\0HidUsb\0\0 > > Now, it seems we should be able to use the SPDRP_LOWERFILTERS key [1] to > retrieve that property, so I am planning to add a fallback to lower > filter to the code shortly. This should work fine as simply adding > libusb0 to the list of known WinUSB API names allowed me to access a > "filtered" device on my machine successfully and the libusb-win32 filter > driver inf seems to work fine on my platform as well. Nice, You should probably check both Upper and Lower filters. > > As to what we should do if both the filter driver and the regular driver > are supported in our backend, right now my view would be to just ignore > the filter driver always, unless we have specific scenario where we see > being able to switch to lower filter as a must have. Otherwise we will > need: > - either a new API call for driver backend selection or the creation of > a fake composite parent device (with one additional interface per filter > driver, though that would be probably abuse the composite device > definition, and we could end up with interfaces of composite devices > being "composite devices" themselves) > - code in most of the libusb API calls to prevent simultaneous access to > the filtered and unfiltered device. > > All in all, supporting user switching between filtered and unfiltered > looks like a lot of effort, as well as adding a lot of complexity, for > benefit that I don't really see ATM. We might however tweak the fallback > between regular and filter driver to try filter first, as I suspect > that, if somebody added a filter, they probably prefer that driver to be > used over regular where possible. I think the problem is how the devices are discovered. I did not change anything in libusbdotnet to get this to work. Using the standard MSDN recommended methods for WinUSB works perfectly. 1) First find all the DeviceInterfaceGUIDs 2) find all the DevicePaths for each device in each device interface GUID 3) remove duplicate device paths and your golden. Regards, Travis |
|
From: Pete B. <pb...@gm...> - 2010-08-18 21:06:46
|
On 2010.08.18 21:01, Travis wrote: > 1) First find all the DeviceInterfaceGUIDs > 2) find all the DevicePaths for each device in each device interface GUID > 3) remove duplicate device paths and your golden. That's what we do (and that was the really easy part to implement actually). If you have a closer look at set_device_paths, you'll see that this is what's actually going on there. The problem is that, when you also need to build the actual USB tree (find the parent child relations), it becomes slightly more complex... ;) Regards, /Pete |
|
From: Travis <tra...@co...> - 2010-08-18 21:39:34
|
> On 2010.08.18 21:01, Travis wrote:
>> 1) First find all the DeviceInterfaceGUIDs
>> 2) find all the DevicePaths for each device in each device interface GUID
>> 3) remove duplicate device paths and your golden.
> Pete Batard wrote:
> That's what we do (and that was the really easy part to implement
> actually). If you have a closer look at set_device_paths, you'll see
> that this is what's actually going on there.
> The problem is that, when you also need to build the actual USB tree
> (find the parent child relations), it becomes slightly more complex... ;)
>
lol.. agreed. Your dealing with a much more complex implementation.
pbr298 is fixed.
Regards,
Travis
Loop Test Information
Vid / Pid : 1234h / 0001h
Interface # : 00h
Priority : Normal
Buffer Size : 4096
Buffer Count : 1
Display Refresh : 1000 (ms)
Transfer Timeout: 5000 (ms)
Retry Count : 0
Verify Data : Off
Bulk Read (Ep81h) max packet size: 64
Total Bytes : 2273280
Total Transfers : 555
Avg. Bytes/sec : 456742.69
Elapsed Time : 4.98 seconds
Bulk Write (Ep01h) max packet size: 64
Total Bytes : 2273280
Total Transfers : 555
Avg. Bytes/sec : 455825.54
Elapsed Time : 4.99 seconds
|
|
From: Tim R. <ti...@pr...> - 2010-08-18 20:18:32
|
Pete Batard wrote: > > Having now had a chance to play with the filter driver device, it looks > like there's a "Device lower filters" entry that is being added when a > filter driver is used and which contains the service name (eg "WinUSB" > of a libusb0.sys filter driver device). Correct. > No idea what happens when there are multiple "Device lower filters" > there (plural, so there could be more than one - space delimiter? > semicolon?). If anybody knows, or has access to a device with multiple > lower filters, feel free to enlighten us with what you see in the > "Device lower filters" property. As Travis points out, the LowerFilters and UpperFilters keys can hold multiple service names, separated by zeros, terminates by two zeros. It works just fine, and is done all the time. CD drives often have multiple filters to support the various different types of CDs. Although it's not part of the contract, filter drivers are loaded in the order they appear in the LowerFilters and UpperFilters keys. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Pete B. <pb...@gm...> - 2010-08-18 20:43:30
|
Thanks for the info. I have just pushed pbr298 (along with binary snapshot) that includes limited support for filter drivers, to confirm that we're on the right track. Only implements support for the first lower filter, I'll add upper and multiple later on. I tested the new libusb DLL against the benchmark device, and it seems to work OK. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-19 13:00:27
|
On Wed, Aug 18, 2010 at 10:25 PM, Xiaofan Chen <xia...@gm...> wrote:
>>
>> I also have doubts about how we would handle a composite parent with a
>> filter driver.
>>
> It seems in this case, libusb-1.0 WinUSB backend will not be able to
> find the device and will not report an error either.
>
> Test case:
> Benchmark firmware, USB composite device, dual Bulk interface.
> libusb-win32 as the function driver for the parent device, WinUSB
> as the lower filter driver.
>
> libusbdotnet works with either WinUSB driver or libusb-win32
> driver, but not libusb10 option.
With pbr298, the above test cases works. This is tested under
Windows 7 32bit.
The device is using libusb-win32 as the function driver
(the whole device).
DLL version: 1.2.1.17
Driver version: 1.2.1.17
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0001--0xffff-0x0005 FFFF/0005
- Manufacturer : LPCUSB
- Product : USBSerial
- Serial Number: DEADC0DE
wTotalLength: 32
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: c0h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 255
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 06h
bmAttributes: 0dh
wMaxPacketSize: 128
bInterval: 1
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 83h
bmAttributes: 0dh
wMaxPacketSize: 128
bInterval: 1
bRefresh: 0
bSynchAddress: 0
bus-0/\\.\libusb0-0002--0x1234-0x0001 1234/0001
- Manufacturer : Travis Robinson
- Product : Dual Benchmark Device
- Serial Number: BMD002
wTotalLength: 55
bNumInterfaces: 2
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: c0h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 0
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 4
bEndpointAddress: 01h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 81h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bInterfaceNumber: 1
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 0
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 5
bEndpointAddress: 02h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 82h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234
pid=0x0001 driver=libusb10 intf=0
LibUsbDotNet USB Benchmark v2.2.7.85
Copyright (c) 2010 Travis Robinson. <lib...@gm...>
website: http://sourceforge.net/projects/libusbdotnet
Benchmark device 1234:0001 opened..
Loop Test Information
Vid / Pid : 1234h / 0001h
Interface # : 00h
Priority : Normal
Buffer Size : 4096
Buffer Count : 1
Display Refresh : 1000 (ms)
Transfer Timeout: 5000 (ms)
Retry Count : 0
Verify Data : Off
Bulk Read (Ep81h) max packet size: 64
Bulk Write (Ep01h) max packet size: 64
While the test is running:
Press 'Q' to quit
Press 'T' for test details
Press 'I' for status information
Press 'R' to reset averages
Press 'Q' to exit, any other key to begin..
Avg. Bytes/s: 510391.62 Transfers: 119 Bytes/s: 510391.62
Avg. Bytes/s: 510691.88 Transfers: 244 Bytes/s: 510978.04
Avg. Bytes/s: 510961.46 Transfers: 369 Bytes/s: 511488.51
qAvg. Bytes/s: 511223.85 Transfers: 494 Bytes/s: 512000.00
stopped Ep81h thread.
stopped Ep01h thread.
Loop Test Information
Vid / Pid : 1234h / 0001h
Interface # : 00h
Priority : Normal
Buffer Size : 4096
Buffer Count : 1
Display Refresh : 1000 (ms)
Transfer Timeout: 5000 (ms)
Retry Count : 0
Verify Data : Off
Bulk Read (Ep81h) max packet size: 64
Total Bytes : 2027520
Total Transfers : 495
Avg. Bytes/sec : 511096.55
Elapsed Time : 3.97 seconds
Bulk Write (Ep01h) max packet size: 64
Total Bytes : 2027520
Total Transfers : 495
Avg. Bytes/sec : 511225.42
Elapsed Time : 3.97 seconds
Press any key to exit..
D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234
pid=0x0001 driver=libusb10 intf=1
LibUsbDotNet USB Benchmark v2.2.7.85
Copyright (c) 2010 Travis Robinson. <lib...@gm...>
website: http://sourceforge.net/projects/libusbdotnet
Benchmark device 1234:0001 opened..
Loop Test Information
Vid / Pid : 1234h / 0001h
Interface # : 01h
Priority : Normal
Buffer Size : 4096
Buffer Count : 1
Display Refresh : 1000 (ms)
Transfer Timeout: 5000 (ms)
Retry Count : 0
Verify Data : Off
Bulk Read (Ep82h) max packet size: 64
Bulk Write (Ep02h) max packet size: 64
While the test is running:
Press 'Q' to quit
Press 'T' for test details
Press 'I' for status information
Press 'R' to reset averages
Press 'Q' to exit, any other key to begin..
Avg. Bytes/s: 511467.22 Transfers: 120 Bytes/s: 511467.22
Avg. Bytes/s: 511214.32 Transfers: 244 Bytes/s: 510969.82
Avg. Bytes/s: 511307.17 Transfers: 369 Bytes/s: 511488.51
Avg. Bytes/s: 511223.85 Transfers: 494 Bytes/s: 510978.04
qAvg. Bytes/s: 511174.19 Transfers: 619 Bytes/s: 510978.04
stopped Ep82h thread.
stopped Ep02h thread.
Loop Test Information
Vid / Pid : 1234h / 0001h
Interface # : 01h
Priority : Normal
Buffer Size : 4096
Buffer Count : 1
Display Refresh : 1000 (ms)
Transfer Timeout: 5000 (ms)
Retry Count : 0
Verify Data : Off
Bulk Read (Ep82h) max packet size: 64
Total Bytes : 2539520
Total Transfers : 620
Avg. Bytes/sec : 511175.52
Elapsed Time : 4.97 seconds
Bulk Write (Ep02h) max packet size: 64
Total Bytes : 2539520
Total Transfers : 620
Avg. Bytes/sec : 511072.65
Elapsed Time : 4.97 seconds
Press any key to exit..
--
Xiaofan
|
|
From: Pete B. <pb...@gm...> - 2010-08-18 15:09:02
|
On 2010.08.18 15:11, Peter Stuge wrote: > Wow, really surprising terminology, but maybe you'll agree that it is > an exception to the normal working case, if the intention is to > access the device. We should try to avoid that something which is an > exception might be interpreted as something positive. This is Windows. Trying to access an USB device that doesn't have a driver on Windows is about as ridiculous as trying to access an IEEE 1394 device with libusb (unless you use a custom Windows kernel, you'll get enumeration, and that's all). Heck, if my enumeration for some reason listed both USB and Firewire (could happen - Microsoft could decide to use a single class GUID for USB + 1394, which we would then use to list devices), and I were to output something like "* FIREWIRE DEVICE *" everytime I had to ignore a 1394 during enum (because it's debug, and I'm free to output whatever I want in debug), you wouldn't come complain that people are going to expect to access their FireWire devices because there's a *DEBUG* message about them during enum. Well, it's exactly the same with driverless. But of course, now I understand where you're coming from. Linux (and possibly Darwin) users are expected to access "driverless" devices, because, well, the kernel has an USB generic *driver* that allows you do so, and then there exists higher level drivers that provide more specific functionality. But if the intention is to access the device, you need a driver, period. Now, if you break down the Linux drivers into lower level and higher level, then you might consider that only the higher level qualifies as a driver, while the lower level is pretty much given, or, as you put it "driving a device without writing a device driver" (except, someone did write a generic driver for the kernel), but trying to restrict the driverless terminology to higher level drivers is probably equally confusing to people who will read "driverless" on Linux as "not having any driver at all", i.e. not even being able to do low level USB access. > "Driverless" is a state, without information about expectations, and > it already has a de-facto meaning of "driving a device without > writing a device driver". This is your (Linux) de-facto. The Windows de-facto would be "device that cannot be accessed at all". I don't mind clarifying the *debug* message (But weren't we supposed not to care about how our users read our *debug* messages by the way? Weren't debug messages something that was only meant to be used internally by us, for development and not something that was meant to be used in a useful manner by our users? Glad to see that you eventually rallied to seeing debug messages as something that our users might want to work with), but you can't simply barge in and assume that Windows people will interpret things in the same manner as Linux people do. My de-facto assumption on Windows is that, if anybody sees driverless, they'll equate this with no device access ever. Regards, /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-08-18 23:51:19
|
On Thu, Aug 19, 2010 at 5:39 AM, Travis <tra...@co...> wrote: >> On 2010.08.18 21:01, Travis wrote: >>> 1) First find all the DeviceInterfaceGUIDs >>> 2) find all the DevicePaths for each device in each device interface GUID >>> 3) remove duplicate device paths and your golden. > >> Pete Batard wrote: >> That's what we do (and that was the really easy part to implement >> actually). If you have a closer look at set_device_paths, you'll see >> that this is what's actually going on there. >> The problem is that, when you also need to build the actual USB tree >> (find the parent child relations), it becomes slightly more complex... ;) >> > > lol.. agreed. Your dealing with a much more complex implementation. > > pbr298 is fixed. > Hmm, does not seem to work for me under Windows 7 x64. I will try to get the debug log this evening. 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 D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234 pid=0x0001 driver=libusb-win32 LibUsbDotNet USB Benchmark v2.2.7.85 Copyright (c) 2010 Travis Robinson. <lib...@gm...> website: http://sourceforge.net/projects/libusbdotnet Benchmark device 1234:0001 opened.. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Bulk Write (Ep01h) max packet size: 64 While the test is running: Press 'Q' to quit Press 'T' for test details Press 'I' for status information Press 'R' to reset averages Press 'Q' to exit, any other key to begin.. Avg. Bytes/s: 510418.13 Transfers: 121 Bytes/s: 510418.13 Avg. Bytes/s: 510961.46 Transfers: 246 Bytes/s: 511488.51 Avg. Bytes/s: 510967.05 Transfers: 371 Bytes/s: 510978.04 qAvg. Bytes/s: 510581.72 Transfers: 495 Bytes/s: 509432.30 stopped Ep81h thread. stopped Ep01h thread. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Total Bytes : 2031616 Total Transfers : 496 Avg. Bytes/sec : 510584.57 Elapsed Time : 3.98 seconds Bulk Write (Ep01h) max packet size: 64 Total Bytes : 2031616 Total Transfers : 496 Avg. Bytes/sec : 510584.57 Elapsed Time : 3.98 seconds Press any key to exit.. D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234 pid=0x0001 driver=winusb LibUsbDotNet USB Benchmark v2.2.7.85 Copyright (c) 2010 Travis Robinson. <lib...@gm...> website: http://sourceforge.net/projects/libusbdotnet Benchmark device 1234:0001 opened.. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Bulk Write (Ep01h) max packet size: 64 While the test is running: Press 'Q' to quit Press 'T' for test details Press 'I' for status information Press 'R' to reset averages Press 'Q' to exit, any other key to begin.. Avg. Bytes/s: 512000.00 Transfers: 117 Bytes/s: 512000.00 Avg. Bytes/s: 511471.62 Transfers: 242 Bytes/s: 510978.04 Avg. Bytes/s: 511477.37 Transfers: 367 Bytes/s: 511488.51 qstopped Ep81h thread. stopped Ep01h thread. Loop Test Information Vid / Pid : 1234h / 0001h Interface # : 00h Priority : Normal Buffer Size : 4096 Buffer Count : 1 Display Refresh : 1000 (ms) Transfer Timeout: 5000 (ms) Retry Count : 0 Verify Data : Off Bulk Read (Ep81h) max packet size: 64 Total Bytes : 2019328 Total Transfers : 493 Avg. Bytes/sec : 511610.84 Elapsed Time : 3.95 seconds Bulk Write (Ep01h) max packet size: 64 Total Bytes : 2019328 Total Transfers : 493 Avg. Bytes/sec : 511610.84 Elapsed Time : 3.95 seconds Press any key to exit.. D:\work\libusbdotnet\LibUsbDotNet_Bin.2.2.7>BenchmarkCon.exe vid=0x1234 pid=0x0001 driver=libusb10 LibUsbDotNet USB Benchmark v2.2.7.85 Copyright (c) 2010 Travis Robinson. <lib...@gm...> website: http://sourceforge.net/projects/libusbdotnet 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) at MonoLibUsb.MonoUsbSessionHandle..ctor() at MonoLibUsb.MonoUsbEventHandler.Init(UnixNativeTimeval unixNativeTimeval) at MonoLibUsb.MonoUsbEventHandler.Init() at MonoLibUsb.MonoUsbApi.InitAndStart() at LibUsbDotNet.LudnMonoLibUsb.MonoUsbDevice.get_MonoUsbDeviceList() at LibUsbDotNet.UsbDevice.get_AllLibUsbDevices() at LibUsbDotNet.BenchmarkConsole2.GetBenchmarkDeviceList(BENCHMARK_TEST_PARAM testParam) at LibUsbDotNet.BenchmarkConsole2.Bench_Open(BENCHMARK_TEST_PARAM test) at LibUsbDotNet.BenchmarkConsole2.Main(String[] argv) -- 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