On 2012.08.08 01:15, Peter Stuge wrote: > I look forward to some testing! Even if it comes at the cost of the > libusbK DLL it's still very nice that libusb-1.0 code can be used > with the libusb-win32 driver.
The use of the K DLL shouldn't be a surprise at this stage. It has announced as the method we'd use of 0/K support for a very long time (at least more than 1 year if not 2). > Both branches (master and 0K) in your personal repo have parents on > libusbx.git master, so I suggest for everyone to simply add a remote > and fetch from that in their existing worktrees, rather than making > new clones. Repositories don't matter at all, only commits matter. Good to know. Not sure it matters much, as I'd encourage the use of separate directories to track mainline and branches. Either way, having people use git in whichever way suits then is 100% fine by me. >> I should also point out that the implementation is very dependent on >> the KUSB_FNID definitions from libusbK and their order, > > This seems fragile. Is there any more robust way? Don't snip the content after the comma. It was placed there precisely to indicate how much the question above would be irrelevant. As usual, it's a bit of an annoyance making sure my approach is explained, only to have you ignore the whole thing and push for your own contrary agenda instead. > Interesting. Is the error definitely coming from the libusb0 driver, > as opposed to libusbK? Looks that way to me. > Which string descriptor is being read from the device by the way I'll care about that when/if I actually look into it. Or you can also take that as a hint that I was mentioning the issue because I wouldn't mind for someone else to check it out, if they have a chance to test and reproduce the problem. I can't really see the issue being linked to the libusbx code, when WinUSB and libusbK don't behave that way, so I could use not having to do the groundwork. My guess is that this XBox controller is only one of many devices that would display this behaviour. > Did Travis help with this code too, besides libusbK providing WinUSB > compatibility? I think part of the filter driver code (which I just refactored) came from him, but that was about it. Had this had been a regular collaborative effort with regards to the code, Travis would be mentioned in the commit. > This is a nice feature, so I think he deserves credit! Don't want to depreciate Travis' effort, which, if you pick up the e-mails mentioning the 0/K integration, you'll find I have actually never failed to thank him for, but should we start crediting every single external feature we are leveraging now? Personally, with regards to commits, I think I'll stick to crediting the person who writes the bulk of the code being pushed. That's what other projects do. Else, since he also did an invaluable amount of testing when the precursor to this patch was being reviewed between the 3 of us more than a year ago, I'd push to also mention Xiaofan along with Travis in the commit. Regards, /Pete PS: I have now tested the filter driver against a mass storage device (i.e. keeping Windows default mass storage driver) and it seems to produce the expected results. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
