On 2012.09.10 06:14, Xiaofan Chen wrote:
> On the other hand, if we can not fix the issue of the
> filter driver with regard to USB composite device, I
> think it is still okay to release 1.0.13, just need to
> put this limitation in the release notes.
That was the plan, as I'd like to go RC tomor
On Sun, Sep 9, 2012 at 8:24 AM, Xiaofan Chen wrote:
> On Sat, Sep 8, 2012 at 1:45 AM, Pete Batard wrote:
>> On 2012.09.07 13:53, Xiaofan Chen wrote:
>>> If I use Zadig to install the filter driver on top of the existing
>>> FTDI driver, "xusb -j" does not work. It seems to me in that
>>> case the
On Sat, Sep 8, 2012 at 1:45 AM, Pete Batard wrote:
> On 2012.09.07 13:53, Xiaofan Chen wrote:
>> If I use Zadig to install the filter driver on top of the existing
>> FTDI driver, "xusb -j" does not work. It seems to me in that
>> case the extra line you add in the inf file does not really
>> do w
On Fri, Sep 7, 2012 at 6:20 AM, Pete Batard wrote:
> But now Zadig v2.0.1.158 has been released...
>
It seems to me you need to update the WDF Coinstaller
since Microsoft has updated it.
http://www.osronline.com/showthread.cfm?link=230798
>From Microsoft's Doron Holan:
"If you downloaded the wdf
On Tue, Aug 28, 2012 at 5:01 PM, Pete Batard wrote:
> I have of course now been able to confirm this, by commenting out the
> disabling of ALLOW_PARTIAL_READS in libusbx, and verifying that it lets
> K complete the mass storage test where it previously failed.
>
I removed the line that disables
On Sat, Sep 8, 2012 at 1:45 AM, Pete Batard wrote:
> On 2012.09.07 13:53, Xiaofan Chen wrote:
>> If I use Zadig to install the filter driver on top of the existing
>> FTDI driver, "xusb -j" does not work. It seems to me in that
>> case the extra line you add in the inf file does not really
>> do w
On 2012.09.07 13:53, Xiaofan Chen wrote:
> If I use Zadig to install the filter driver on top of the existing
> FTDI driver, "xusb -j" does not work. It seems to me in that
> case the extra line you add in the inf file does not really
> do what it supposed to do.
Haven't had a chance to try the fi
On Fri, Sep 7, 2012 at 6:20 AM, Pete Batard wrote:
> On 2012.09.06 15:02, Xiaofan Chen wrote:
>> Since you have not released the update Zadig yet.
>
> Well, I said 24 hours, which, due to various circumstances, I very much
> meant. But now Zadig v2.0.1.158 has been released...
Okay, I tested usin
On 2012.09.06 15:02, Xiaofan Chen wrote:
> Since you have not released the update Zadig yet.
Well, I said 24 hours, which, due to various circumstances, I very much
meant. But now Zadig v2.0.1.158 has been released...
Not sure when I'll release libwdi, as there's one last issue that I'd
like to
On Thu, Sep 6, 2012 at 9:56 PM, Xiaofan Chen wrote:
> On Thu, Sep 6, 2012 at 6:26 AM, Pete Batard wrote:
>> OK, IMO, the best way to address that last issue we have with libusb0 as
>> composite device is by modifying the libusb0 inf file to create a Device
>> Interface GUID during installation.
>
On Thu, Sep 6, 2012 at 6:26 AM, Pete Batard wrote:
> OK, IMO, the best way to address that last issue we have with libusb0 as
> composite device is by modifying the libusb0 inf file to create a Device
> Interface GUID during installation.
>
> In this case, this is really a one liner change in libw
On Tue, Sep 4, 2012 at 6:45 AM, Pete Batard wrote:
> Just an update. I now have a partial patch for composite support, that
> appears to works fine with WinUSB and libusbK, but still doesn't
> properly set the interfaces for libusb0.
Just checked the latest git and it indeed solved the problems
I
On Thu, Sep 6, 2012 at 6:26 AM, Pete Batard wrote:
> OK, IMO, the best way to address that last issue we have with libusb0 as
> composite device is by modifying the libusb0 inf file to create a Device
> Interface GUID during installation.
>
> In this case, this is really a one liner change in libw
OK, IMO, the best way to address that last issue we have with libusb0 as
composite device is by modifying the libusb0 inf file to create a Device
Interface GUID during installation.
In this case, this is really a one liner change in libwdi:
--- "a/D:\\libwdi\\libwdi\\libusb0.inf.in"
+++ "b/D:\\l
Just an update. I now have a partial patch for composite support, that
appears to works fine with WinUSB and libusbK, but still doesn't
properly set the interfaces for libusb0.
Part of the problem is that, unlike WinUSB and libusbK, libusb0 doesn't
provide an extra device interface GUID that we
[1]
https://github.com/libusbx/libusbx/commit/e82c677b5f10a966c89f6b58caa1ae4341260527
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed an
Many thanks for the tests.
It looks like composite is broken alright, and has been since 10540
[1]. There's some breakage in set_composite_interface(), where the
change introduced in 10540 means we're only getting one interface
populated, and I'm also seeing file handles not being initialized on
On Sun, Sep 2, 2012 at 9:49 AM, Pete Batard wrote:
> On 2012.08.31 11:13, Xiaofan Chen wrote:
>> I have seen some potential issues with USB composite
>> device (FT2232H based JTAG debugger) with libusbK or
>> libusb0.sys (filter or device driver) when I tested OpenOCD
>> 0.6.0-rc2 with libusbx git
On 2012.08.31 11:13, Xiaofan Chen wrote:
> I have seen some potential issues with USB composite
> device (FT2232H based JTAG debugger) with libusbK or
> libusb0.sys (filter or device driver) when I tested OpenOCD
> 0.6.0-rc2 with libusbx git. I will try to use xusb to replicate
> the issues and pos
On Fri, Aug 31, 2012 at 3:13 AM, Xiaofan Chen wrote:
> If it is possible, please test with some USB Composite device
> as well. Thanks.
>
>
Sure, we have some webcams and such. I should probably start trying out
xusb, we haven't used it here yet.
Dave
---
On Fri, Aug 31, 2012 at 4:47 PM, David Grant wrote:
> FWIW, I've finally got a chance to build and test libusb with Windows with
> our software and I'm also seeing the same thing as above (I'm using libusbK)
> with a mass storage device. I was so impressed that everything else just
> worked though
On Sat, Aug 25, 2012 at 3:03 AM, Xiaofan Chen wrote:
> [ 0.518200] [11a8] libusbx: debug [winusbx_submit_bulk_transfer]
> matched end
> point 81 with interface 0
> [ 0.518200] [11a8] libusbx: debug [winusbx_submit_bulk_transfer]
> reading 36
> bytes
> [ 0.519200] [11a8] libusbx: debug
Hi,
On 08/30/2012 05:43 AM, Kustaa Nyholm wrote:
> On 30.8.2012 4.21, "Pete Batard" wrote:
>>
>> I doubt I'm the only one who'd prefer an API that solves actual
>> problems, such as setting platform specific preferences, over an API
>> that's been over sanitized for the sake of abstraction.
>
> I
On Wed, Aug 29, 2012 at 8:43 PM, Kustaa Nyholm
wrote:
> On 30.8.2012 4.21, "Pete Batard" wrote:
> >
> >I doubt I'm the only one who'd prefer an API that solves actual
> >problems, such as setting platform specific preferences, over an API
> >that's been over sanitized for the sake of abstraction.
On 30.8.2012 4.21, "Pete Batard" wrote:
>
>I doubt I'm the only one who'd prefer an API that solves actual
>problems, such as setting platform specific preferences, over an API
>that's been over sanitized for the sake of abstraction.
I'm with you on this one.
br Kusti
-
On 2012.08.29 10:34, Xiaofan Chen wrote:
> The flags are there for a reason. So maybe it is
> a good idea to provide an API for the users to choose
> the option. Probably for next libusb 1.1... "
>
> On the other hand, such API will have some platform
> specific options and some people may not like
On 2012.08.29 02:30, Xiaofan Chen wrote:
> It is great that you found and confirmed the issue. I was thinking along
> this line but had a quick look into the codes but was not able to find this.
Well, you certainly pointed me in the right direction. I just followed
what you pointed your finger to
On Wed, Aug 29, 2012 at 9:30 AM, Xiaofan Chen wrote:
> On Wed, Aug 29, 2012 at 8:01 AM, Pete Batard wrote:
>> Now, with regards to where in libusbx or libusbK lies the problem, in
>> xusb, we do call libusb_bulk_transfer() and tell it we expect 36 bytes,
>> which is what K also indicates we recei
On Wed, Aug 29, 2012 at 8:01 AM, Pete Batard wrote:
> On 2012.08.28 13:11, Xiaofan Chen wrote:
>>> Right now, and just like your tests, I'm pretty much seeing a read
>>> failure against any mass storage device I try, when using the libusbK
>>> driver.
>>
>> Please refer to previous reply to that o
First link is off. Should be:
[1]
https://sourceforge.net/p/libusbk/code/268/tree/trunk/libusbK/src/sys/drv_xfer_bulk.c#l68
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security
On 2012.08.28 13:11, Xiaofan Chen wrote:
>> Not really. The mass storage test of xusb should work. It's there to
>> demonstrate the libusbx capabilities against USB devices that are mass
>> storage, and there's no real reason it should fare worse than Windows in
>> that respect.
>
> I mean 'xusb -k
On Tue, Aug 28, 2012 at 5:55 AM, Pete Batard wrote:
libusbx: info [get_interface_details_filter] assigned libusb0 symbolic
link \\.\
libusb0-0001
>>>
>>> Mmm, maybe we should set that info message to debug? What do you think?
>>> Not the message is that informational after all...
>
On Tue, Aug 28, 2012 at 5:55 AM, Pete Batard wrote:
> On 2012.08.27 10:10, Xiaofan Chen wrote:
It seems to me "xusb -k" does not work well with some
USB Flash Drive like the Sandisk 8GB drive and a
Kingston 1GB drive I have, even with a real Windows 7
x64 machine.
>>>
>>> Yeah,
On Tue, Aug 28, 2012 at 5:55 AM, Pete Batard wrote:
> On 2012.08.27 10:10, Xiaofan Chen wrote:
4) libusbk.sys --> does not work well.
>>>
>>> Yup... I'll try to see if we can get some more info with the debug driver.
>>
>> Are you able to reproduce the issue? I think the debug driver should
>
On Mon, Aug 27, 2012 at 5:10 PM, Xiaofan Chen wrote:
>>> 3) libusb0.sys --> works fine, with one warning message
>>>
>>> Reading string descriptors:
>>> String (0x01): "Generic"
>>> String (0x02): "Flash Disk"
>>> libusbx: error [winusbx_submit_control_transfer] ControlTransfer failed:
>>
On Mon, Aug 27, 2012 at 5:10 PM, Xiaofan Chen wrote:
> On Mon, Aug 27, 2012 at 7:21 AM, Pete Batard wrote:
>> On 2012.08.25 10:52, Xiaofan Chen wrote:
>>> 1) libusb-win32 filter driver + original Windows driver usbstor.sys
>>> --> works fine, with a few warning messages
>>>
>>> Claiming interface
On 2012.08.27 10:10, Xiaofan Chen wrote:
>>> It seems to me "xusb -k" does not work well with some
>>> USB Flash Drive like the Sandisk 8GB drive and a
>>> Kingston 1GB drive I have, even with a real Windows 7
>>> x64 machine.
>>
>> Yeah, I'm seeing some of those issues too.
>
> I think this is pre
On Mon, Aug 27, 2012 at 7:21 AM, Pete Batard wrote:
> On 2012.08.25 10:52, Xiaofan Chen wrote:
>> It seems to me "xusb -k" does not work well with some
>> USB Flash Drive like the Sandisk 8GB drive and a
>> Kingston 1GB drive I have, even with a real Windows 7
>> x64 machine.
>
> Yeah, I'm seeing
On 2012.08.25 10:52, Xiaofan Chen wrote:
> It seems to me "xusb -k" does not work well with some
> USB Flash Drive like the Sandisk 8GB drive and a
> Kingston 1GB drive I have, even with a real Windows 7
> x64 machine.
Yeah, I'm seeing some of those issues too.
> The strange thing is that
> libus
On Wed, Aug 22, 2012 at 10:06 PM, Xiaofan Chen wrote:
> On Mon, Aug 20, 2012 at 8:32 AM, Pete Batard wrote:
>> Hopefully will help getting more testing before next release.
>>
>> I'm closing #11 and #12 as a result (isoc support will be dealt elsewhere).
>>
>> I also pushed the patch provided for
On Mon, Aug 20, 2012 at 8:32 AM, Pete Batard wrote:
> Hopefully will help getting more testing before next release.
>
> I'm closing #11 and #12 as a result (isoc support will be dealt elsewhere).
>
> I also pushed the patch provided for #41
> (https://github.com/libusbx/libusbx/pull/41).
>
The te
Hopefully will help getting more testing before next release.
I'm closing #11 and #12 as a result (isoc support will be dealt elsewhere).
I also pushed the patch provided for #41
(https://github.com/libusbx/libusbx/pull/41).
Also please note that github decided to stop pushing issues update to
42 matches
Mail list logo
