On Wed, May 2, 2012 at 2:40 PM, 付帅兵 wrote:
> 1.The Linux distro is ubuntu9.10 and the kernel is 2.6.24.
> 2.the kernel is not debug , so the relevant output of "dmesg" is only "usb
> 1-6: USB disconnect, address 13".
So the device got kicked out by the kernel and most likely
the device is buggy
1.The Linux distro is ubuntu9.10 and the kernel is 2.6.24.
2.the kernel is not debug , so the relevant output of "dmesg" is only "usb 1-6:
USB disconnect, address 13".
3. for Most of U disk the user mode driver is ok, but for a few U disk
which is made by Unknow manufacturer, it is not
On Wed, May 2, 2012 at 1:35 PM, 付帅兵 wrote:
> I used libusbx which version is 1.0.10 for LINUX OS,
> copy data from PC to U disk, sometimes the device disapeared for
> special U disk.
> I look for code and find the libusb_interrupt_or_bulk_transfer return
> error which
> is " libusb_interrup_or
I used libusbx which version is 1.0.10 for LINUX OS,
copy data from PC to U disk, sometimes the device disapeared for special U
disk.
I look for code and find the libusb_interrupt_or_bulk_transfer return error
which is " libusb_interrup_or_bulk_transfer read fail:
LIBUSB_ERROR_NO_DEVICE
Reference: http://www.osronline.com/showthread.cfm?link=223812
In the above thread, Microsoft's Doron Holan (Windows driver
expert) answered Microsoft's view on the perceived WinUSB
limitations.
I think this is of good reference to the list member here.
Q1. WinUSB cannot be used to send an actua
On Wed, May 2, 2012 at 5:53 AM, Peter Stuge wrote:
> Pete Batard wrote:
>> please note that, while maintainer of the original branch of
>> libusb, Peter Stuge is neither a maintainer nor a moderator of
>> libusbx, and as such he does not speak with any authority on this
>> list. As such, he may no
On Wed, May 2, 2012 at 4:00 AM, Pete Batard wrote:
> Hi Uri,
>
> Thanks for this. The usbi_fd_notification calls were indeed
> inadvertently removed, and I have now pushed your fix to the
> git repository.
>
> I expect versions of libusbx running on Windows without this fix to be
> fairly severely
2012/5/1 Pete Batard :
> By the way, do you still consider the update of version.h and the
> running of autotools that results as something you want to see fixed? As
> I said, we can move the nano into its own nano.h to avoid the issue, but
> I'm not sure of how important you or anybody else sees t
Pete Batard wrote:
> please note that, while maintainer of the original branch of
> libusb, Peter Stuge is neither a maintainer nor a moderator of
> libusbx, and as such he does not speak with any authority on this
> list. As such, he may not be up to speed with previous work that
> occurred on th
On Tue, May 1, 2012 at 2:17 PM, Pete Batard wrote:
> On 2012.04.29 06:42, Arnon Gilboa wrote:
> >> I see that you used wdi_register_logger() in an "Hack for wdi logging"
> >> section (currenlty disabled).
> >> Can you elaborate on the limitation you found there and if you would
> >> like an enhan
On 2012.05.01 22:05, Ludovic Rousseau wrote:
> If the only benefit of running ./configure in autogen.sh is speed on
> Windows I propose to use an opt-in option and run ./configure only on
> Windows or if requested.
Speed was part of it. But we also found a few examples of autogen.sh
that called o
On 2012.05.01 15:34, Uri Lublin wrote:
>> Assuming you don't need to change the device's install class,
>
> I'm think that assumption is not true with WinUSB based libusb driver.
> A new install class is created for all WinUSB libusb devices.
> (Maybe we can make use the same class used for USB dev
On 2012.04.29 06:42, Arnon Gilboa wrote:
>> I see that you used wdi_register_logger() in an "Hack for wdi logging"
>> section (currenlty disabled).
>> Can you elaborate on the limitation you found there and if you would
>> like an enhancement of libwdi's logging facility?
>>
> I simply wanted wdi u
2012/5/1 Pete Batard :
> On 2012.05.01 16:56, Uri Lublin wrote:
>> For example usefull when running autogen.sh in src-dir and
>> running configure in a (different) build-dir.
>
> We had a discussion previously (on a different mailing list) about
> removing the call to configure altogether, but the
On 2012.05.01 16:52, Uri Lublin wrote:
> Only if old backend api is UNSUPPORTED.
>
> This happens when a libusb driver (e.g. WinUSB) is installed
> after a device has been setup/discovered (with get_device_list).
>
> ---
>
> We want to install libusb driver for USB devices dynamically following a
>
On 2012.05.01 16:56, Uri Lublin wrote:
> For example usefull when running autogen.sh in src-dir and
> running configure in a (different) build-dir.
We had a discussion previously (on a different mailing list) about
removing the call to configure altogether, but the outcome was fairly
mixed, as s
Hi Uri,
Thanks for this. The usbi_fd_notification calls were indeed
inadvertently removed, and I have now pushed your fix to the git repository.
I expect versions of libusbx running on Windows without this fix to be
fairly severely impacted, when the library is used for non-trivial
operations,
Uri Lublin wrote:
> Only if old backend api is UNSUPPORTED.
>
> This happens when a libusb driver (e.g. WinUSB) is installed
> after a device has been setup/discovered (with get_device_list).
I think this is a bug in the Windows backend. _get_device_list()
should never re-use data from a previous
Uri Lublin wrote:
> For example usefull when running autogen.sh in src-dir and
> running configure in a (different) build-dir.
> ---
> autogen.sh |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/autogen.sh b/autogen.sh
> index 782bec7..2a05191 100755
> --- a/autoge
Uri Lublin wrote:
> > Commit 4cccbed825fe1dc13812 removes the possibility to choose between
> > DYNAMIC_FDS and not, and makes the previously optional behavior
> > enforced, so the code in !defined() was likely removed on purpose.
> > (DYNAMIC_FDS was on by default, so it has always been used on Wi
Arnon Gilboa wrote:
> Seems like much more than setting the service.
> Any idea if some of this changes can be dropped?
Many of them just don't matter. They are copied here from the INF file
and are used only for the Device Manager user interface.
> $ diff usbstor1307.reg winusb1307.reg
> 20,24c
Arnon Gilboa wrote:
>
> Do we still need to prepare the driver (patch the inf for the specific
> vid-pid and sign a cat file) or just replace "USBSTOR" to "WinUSB"?
> How does it know where to find the new driver ("service")?
If you're are dinking with driver installation, you really should kn
Only if old backend api is UNSUPPORTED.
This happens when a libusb driver (e.g. WinUSB) is installed
after a device has been setup/discovered (with get_device_list).
---
We want to install libusb driver for USB devices dynamically following a
request by users. There is a problem however to acces
For example usefull when running autogen.sh in src-dir and
running configure in a (different) build-dir.
---
autogen.sh |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index 782bec7..2a05191 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -15,4 +15,6
On 04/30/2012 08:44 PM, Tim Roberts wrote:
> Arnon Gilboa wrote:
>> Tim Roberts wrote:
>>> although I suspect it
>>> would be easier just to rewrite the Enum registry entry to switch to the
>>> new service.
>>>
>> Can you pls explain this point?
> Assuming you don't need to change the device's inst
On 05/01/2012 04:59 PM, Peter Stuge wrote:
> Uri Lublin wrote:
>> Commit 4cccbed825fe1dc13812 accidently removed those calls,
>> when ! ifdef DYNAMIC_FDS blocks were removed.
> Commit 4cccbed825fe1dc13812 removes the possibility to choose between
> DYNAMIC_FDS and not, and makes the previously opti
Arnon Gilboa wrote:
> Tim Roberts wrote:
>
>> Arnon Gilboa wrote:
>>
>>
>>> Tim Roberts wrote:
>>>
>>>
although I suspect it
would be easier just to rewrite the Enum registry entry to switch to the
new service.
>>> Can you pls
Uri Lublin wrote:
> Commit 4cccbed825fe1dc13812 accidently removed those calls,
> when ! ifdef DYNAMIC_FDS blocks were removed.
Commit 4cccbed825fe1dc13812 removes the possibility to choose between
DYNAMIC_FDS and not, and makes the previously optional behavior
enforced, so the code in !defined()
Tim Roberts wrote:
> Arnon Gilboa wrote:
>
>> Tim Roberts wrote:
>>
>>> although I suspect it
>>> would be easier just to rewrite the Enum registry entry to switch to the
>>> new service.
>>>
>>>
>> Can you pls explain this point?
>>
>
> Assuming you don't need to change the
Commit 4cccbed825fe1dc13812 accidently removed those calls,
when ! ifdef DYNAMIC_FDS blocks were removed.
---
libusb/os/windows_usb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 709157a..1957964 100644
--- a/lib
30 matches
Mail list logo
