On Thu, Mar 7, 2013 at 5:32 AM, Pete Batard 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
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?
I'm kind of getting conflicting data f
On Wed, Mar 6, 2013 at 8:04 AM, Xiaofan Chen wrote:
> On Wed, Mar 6, 2013 at 4:59 AM, Pete Batard wrote:
>> I have now pushed the patch reversal to mainline, and closed #96 since
>> by all account we should be sending 0xC1 as expected, and at least with
>> the device I tested against, I have yet
On Wed, Mar 6, 2013 at 8:04 AM, Xiaofan Chen wrote:
> The patch looks correct. However, with the benchmark firmware, I do not
> have issues without the patch but have issues with the patch. Again,
> kind of strange. Tested under Windows 7 x86.
>
> mcuee@mcuee-PC /c/work/libusbx/libusbx
> $ ./examp
On Wed, Mar 6, 2013 at 4:59 AM, Pete Batard wrote:
> On 2013.03.05 14:50, Xiaofan Chen wrote:
>> It is kind of strange under Mac OS X. I can not get it to work with the
>> current git.
>
> Works for me (TM), using the first patch you highlighted below.
> Granted I'm using a intosh and used the exi
On 2013.03.05 14:50, Xiaofan Chen wrote:
> It is kind of strange under Mac OS X. I can not get it to work with the
> current git.
Works for me (TM), using the first patch you highlighted below.
Granted I'm using a intosh and used the existing benchmark device
custom descriptor stack (I wish I had
On Tue, Mar 5, 2013 at 8:27 AM, Pete Batard wrote:
> On 2013.03.03 14:45, Xiaofan Chen wrote:
>> Indeed it works better when going back to older version. Still that
>> older version failed to get the Extended Properties OS Feature Descriptor.
>
> Have you tried using os_fd[i].recipient for both re
On 2013.03.03 14:45, Xiaofan Chen wrote:
> Indeed it works better when going back to older version. Still that
> older version failed to get the Extended Properties OS Feature Descriptor.
Have you tried using os_fd[i].recipient for both requests? Simply
reverting the patch will not do, as there i
On Fri, Mar 1, 2013 at 5:42 AM, Pete Batard wrote:
> On 2013.02.28 03:07, Xiaofan Chen wrote:
>> The extended properties OS feature descriptor failed because it must be
>> directed to the WinUSB interface (LIBUSB_RECIPIENT_INTERFACE),
>> not the device (LIBUSB_RECIPIENT_DEVICE). The first byte of
On Fri, Mar 1, 2013 at 5:42 AM, Pete Batard wrote:
> But there should still be an issue when using interface with WinUSB, as
> it overrides the low byte of wIndex with the destination interface: [3]
>
> [3] http://www.lvr.com/forum/index.php?topic=331
>
The following is from Tim Roberts.
http://w
On 2013.02.28 03:07, Xiaofan Chen wrote:
> The extended properties OS feature descriptor failed because it must be
> directed to the WinUSB interface (LIBUSB_RECIPIENT_INTERFACE),
> not the device (LIBUSB_RECIPIENT_DEVICE). The first byte of the
> Setup packet should be C1h, not C0h. (I didn't try
Ref: http://www.microchip.com/forums/m707870.aspx
As per Jan Axelson (Author of "USB Complete" and other books),
xusb may have a problem when dealing with the extended properties
OS feature descriptor.
Quote: "I tried libusbx with Microchip's WinUSB example and got the
extended compatibility OS f
12 matches
Mail list logo
