|
From: David G. <dav...@gm...> - 2023-07-22 06:53:15
|
Unfortunately, the GUID is a fundamental requirement for WinUSB as far as I can tell. As a low level in libusb and similar libraries, the GUID is part of the name of the file that you actually open to access the device. You can easily generate your own with a utility like uuidgen. --David Grayson On Fri, Jul 21, 2023 at 6:56 PM RisingEdgeIndustries < su...@ri...> wrote: > Do you have to pass a GUID value to get WINUSB to be associated with a > composite device using MS OS 2.0 descriptors? I thought this unique > identifier was optional in case you wanted it in the registry to find your > device? > > > > > > On Tue, Jul 18, 2023 at 1:16 AM Tim Roberts <ti...@pr...> wrote: > >> On 7/17/23 7:01 PM, RisingEdgeIndustries wrote: >> >> >> *Question 1:* >> It seems the key to MS OS 2.0 Descriptors is to set the bcdUSB field to >> USB version 2.1 with a hex value of 0x0210. This is pretty >> straightforward, but as I"m using a USB 2.0 full speed device right now I >> want to make sure there isn't something I'm missing that would render this >> MS OS 2.0 descriptor approach incompatible due to a USB 2.0 full speed >> device setting its bcdUSB version to 2.1. Is this bcdUSB field only to >> tell windows which MS OS descriptor version is supported or does it play a >> role in determining other operational metrics? I'm a little unsure because >> the field defines *"USB Specification number which the device complies >> to"*. This leads me to believe I can't just plug in 0x0210 to get MS OS >> 2.0 descriptors - there are other thing associated with using this value >> over 0x0200 which I'm using now for MS OS v1.0 descriptors >> >> There should be no incompatible changes -- there almost never are when >> the version changes. Microsoft uses the BOS to find out whether the OS 2.0 >> descriptors are present, and the BOS is only supported with USB 2.1. >> >> >> *Question 2:* >> I read that WINUSB (I guess this is more a WINUSB thing than libusb1.0) >> doesn't support access from multiple applications. >> >> Yes, although that's not the only driver that has that limitation. >> Sharing a USB device between multiple applications is very tricky. >> >> >> My goal is to have a logically asynchronous feel to the HID interface by >> allowing a thread to monitor it and when data is present grab it and hand >> it off to the main application thread. >> >> That's fine; it's kind of how the USB HID drivers work. >> >> >> The reason I ask Question #2 is because I tried this with libusb1.0 and >> didn't know how to handle the two interfaces. If I"m correct in my >> understanding that this approach will work, what is the correct way to get >> a hold of these two interfaces in the same application? Do I make two >> device handles and have one device handle the HID interface and the other >> device handle the bulk interface. >> >> Yep, that's how you do it. >> -- >> >> Tim Roberts, ti...@pr... >> Providenza & Boekelheide, Inc. >> >> _______________________________________________ >> libusb-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libusb-devel >> > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |