On Thu, Mar 7, 2013 at 5:32 AM, Pete Batard <p...@akeo.ie> wrote: > On 2013.03.06 02:20, Xiaofan Chen wrote: >> Okay, I tested with different driver and libusbk.sys/libusb0.sys are both >> okay with the latest git. > > Thanks for the test. My understanding is that this was with the > Microchip stack and that OS X and Linux work too?
Yes that is right. > I'm kind of getting conflicting data from your posts in the mailing list > and the addon to the issue. Sorry about that. Basically 04d8:0053 is the official Microchip WinUSB Demo which has the WinUSB OS Descriptor. 04d8:fa2e is the benchmark firmware where older Microchip stack is used and you added the WinUSB OS Descriptor implementation. >> So the problem is only with winusb. The >> issue may be what you have stated in the original code. >> >> // NB: We should use os_fd[i].recipient instead of >> LIBUSB_RECIPIENT_DEVICE above, as >> // LIBUSB_RECIPIENT_INTERFACE should be used for the Extended Properties. >> // However, for Interface requests, the WinUSB DLL forces the low byte of >> wIndex >> // to the interface number, regardless of what you set it to, so we have to >> // fallback to Device and hope the firmware answers both equally. >> // See http://www.lvr.com/forum/index.php?topic=331 > > Yeah, I do expect issues with WinUSB and a firmware that only answers to > INTERFACE. But I didn't know what to do with that comment, since I > expected libusb0 and libusbK to work (though I couldn't confirm it with > the firmware I used). The new Microchip stack only deals with the Interface for the extended properties OS feature descriptor. It also only deals with extended compatibility OS feature descriptor when the vendor specific control request is targeting the device. The benchmark firmware implementation does not seem to check the target of the vendor control request. So I am not so sure why it failed with WinUSB driver. I do not see anything wrong with the Microchip stack other than the ROM thingy. But again that will take time to investigate. The stack is now much more complicated than before. Ref: http://www.microchip.com/forums/m707870.aspx > I was pretty sure we had this documented in the "Known limitations" for > WinUSB already, but I have just found out that this wasn't the case, so > I have added it. Last time we removed that due to the reply from Tim and Doron. Ref: http://www.osronline.com/showthread.cfm?link=223812 >> I think the patch is anyway correct and Ticket 96 can be closed. >> But a note on WinUSB may be necessary here. > > I'll leave you decide if you think this needs to be documented further > in the code (or elsewhere) and send a patch or update the website if you > feel like it. ;) > > NB: it should be fairly straightforward to confirm that the WinUSB > limitation is indeed what is causing the issue using the netmon with the > Win7 USB tracing facility, and comparing a libusb0/libusbK trace with a > WinUSB one. I will take note of that. I am still thinking that there should be a fix somewhere to get WinUSB working. -- Xiaofan ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
