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(-4 ) ".
Must pull out and insert U disk again!
The phenomenon is not inevitable !
What I do ?
thanks!
From: libusbx-devel-request
Date: 2012-05-02 13:04
To: libusbx-devel
Subject: libusbx-devel Digest, Vol 3, Issue 4
Send libusbx-devel mailing list submissions to
libusbx-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
or, via email, send a message with subject or body 'help' to
libusbx-devel-requ...@lists.sourceforge.net
You can reach the person managing the list at
libusbx-devel-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of libusbx-devel digest..."
Today's Topics:
1. Re: [PATCH] autogen.sh: do not run ./configure if
$NOCONFIGURE env-var is defined (Pete Batard)
2. Re: usbclerk: Windows service for signing and installing usb
device drivers (Orin Eman)
3. Re: [PATCH] windows_usb: submit_*_transfer: call
usbi_fd_notification (Peter Stuge)
4. Re: [PATCH] autogen.sh: do not run ./configure if
$NOCONFIGURE env-var is defined (Ludovic Rousseau)
5. Re: [PATCH] windows_usb: submit_*_transfer: call
usbi_fd_notification (Xiaofan Chen)
6. Re: [PATCH] windows_usb: submit_*_transfer: call
usbi_fd_notification (Xiaofan Chen)
7. Microsoft's view on the perceived WinUSB limitations
(Xiaofan Chen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 May 2012 22:34:26 +0100
From: Pete Batard <p...@akeo.ie>
Subject: Re: [Libusbx-devel] [PATCH] autogen.sh: do not run
./configure if $NOCONFIGURE env-var is defined
To: libusbx-devel@lists.sourceforge.net
Message-ID: <4fa056e2.1030...@akeo.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
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 on configure.
> I found some references:
> - glib [1] uses $NOCONFIGURE
> - gst-editor [2] uses ./autogen.sh --noconfigure
Glib is fairly high profile, so that's good enough for me.
> If the default is to call ./configure
I'd personally prefer it, as I could use not wasting additional time on
Windows either having to monitor the completion of one step before
manually launching the next, adding extra options or creating files each
time I run a clean build, since it's by far the slowest platform when
using autotools.
> I would like to be able to
> select the opt-out option by just (and permanently) creating a file
> like .noconfigure.
Sounds fair and simple to implement. Let's see what others say.
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 that issue right now.
Regards,
/Pete
------------------------------
Message: 2
Date: Tue, 1 May 2012 14:34:45 -0700
From: Orin Eman <orin.e...@gmail.com>
Subject: Re: [Libusbx-devel] usbclerk: Windows service for signing and
installing usb device drivers
To: libusbx-devel@lists.sourceforge.net
Message-ID:
<capjy7u_kwc5aa88mwhswnogsvojt49cszp8mp1jb2_-rnqb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, May 1, 2012 at 2:17 PM, Pete Batard <p...@akeo.ie> 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 enhancement of libwdi's logging facility?
> >>
> > I simply wanted wdi used by the service to log to a file instead of a
> > pipe/stdout, so I gave it dummy args and patched about 5 lines in the
> > libwdi logger code. Do you think my patch for that will be useful by
> others?
>
> Not sure. My current view is that standard Windows applications (even
> ones that don't actually have a visible Window, such as a service) that
> want to get some logging and can't use stdout would use the standard
> Windows messaging functionality, even if that means creating a hidden
> Windows where the messages can be directed to. This is what
> wdi_register_logger() provides, and because the creation of windows is
> the core of Windows, the overhead is expected to be minimal.
>
If I'm not a service, I use the following to get logging output to a
console window:
AllocConsole();
freopen("CONOUT$", "a", stdout);
Otherwise, I use CreateFile/WriteFile to write to a file. (I have to use
the native windows calls if I want to set sharing modes such that I can
read the file while my executable is running, otherwise an freopen on
stdout or stderr would do the trick.)
Orin.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Tue, 1 May 2012 23:53:20 +0200
From: Peter Stuge <pe...@stuge.se>
Subject: Re: [Libusbx-devel] [PATCH] windows_usb: submit_*_transfer:
call usbi_fd_notification
To: libusbx-devel@lists.sourceforge.net
Message-ID: <20120501215320.22649.qm...@stuge.se>
Content-Type: text/plain; charset=us-ascii
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 this project
I play very little if any role in the libusbx project, but I do try
to stay up to speed with both the libusb and the libusbx code, which
is so far easy since there are few differences.
> and his opinions should be treated as purely his own.
I'd suggest to treat my opinions as being in the context of the
libusb project.
Since the libusb and the libusbx code is so similar, my contributions
may be useful also in the libusbx project. I certainly feel that
contributions to libusbx can be useful for libusb, and specifically
because the two libraries share similar values in their API and many
man-years worth of code in their implementation I try to participate
also in libusbx discussion. The more participation the better, to
simplify things a bit.
//Peter
------------------------------
Message: 4
Date: Wed, 2 May 2012 00:25:54 +0200
From: Ludovic Rousseau <ludovic.rouss...@gmail.com>
Subject: Re: [Libusbx-devel] [PATCH] autogen.sh: do not run
./configure if $NOCONFIGURE env-var is defined
To: libusbx-devel@lists.sourceforge.net
Message-ID:
<cagste8c_g09nfkvtttc96_vz6hmqkg0cwwzu_e4cu8nwzkr...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2012/5/1 Pete Batard <p...@akeo.ie>:
> 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 that issue right now.
I do not see why "git commit" should automatically update version.h in
the first place.
Users should use a _released_ source tarball or binary installer so
major, minor, micro is enough.
Developers should use git and know what version they use.
In a RERO world normal users should not use a git version.
I have no objection to provide intermediary/test versions with a mano
version. But that can be managed locally by the developer providing
the intermediary version. No need to store the nano version in git.
Bye
--
?Dr. Ludovic Rousseau
------------------------------
Message: 5
Date: Wed, 2 May 2012 07:51:26 +0800
From: Xiaofan Chen <xiaof...@gmail.com>
Subject: Re: [Libusbx-devel] [PATCH] windows_usb: submit_*_transfer:
call usbi_fd_notification
To: libusbx-devel@lists.sourceforge.net
Message-ID:
<CAGjSPUANGXUdJOyU=8Omp3xKOvGzw9A92NfHoKATV4ud=wz...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 2, 2012 at 4:00 AM, Pete Batard <p...@akeo.ie> 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 impacted, when the library is used for non-trivial
> operations, so, depending on what the other maintainers' opinion is, I
> would like to go for an out of band release (by the end of the week) of
> libusbx to make sure Windows users can benefit from this fix ASAP.
>
I think this is good to have.
--
Xiaofan
------------------------------
Message: 6
Date: Wed, 2 May 2012 07:53:34 +0800
From: Xiaofan Chen <xiaof...@gmail.com>
Subject: Re: [Libusbx-devel] [PATCH] windows_usb: submit_*_transfer:
call usbi_fd_notification
To: libusbx-devel@lists.sourceforge.net
Message-ID:
<cagjspucqfuouk4w4ooagwwqxcwc6pjeqikankqzbylfh8dm...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 2, 2012 at 5:53 AM, Peter Stuge <pe...@stuge.se> 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 not be up to speed with previous work that
>> occurred on this project
>
> I play very little if any role in the libusbx project, but I do try
> to stay up to speed with both the libusb and the libusbx code, which
> is so far easy since there are few differences.
Good.
>
>> and his opinions should be treated as purely his own.
>
> I'd suggest to treat my opinions as being in the context of the
> libusb project.
That should be okay as you are the libusb maintainer.
> Since the libusb and the libusbx code is so similar, my contributions
> may be useful also in the libusbx project. I certainly feel that
> contributions to libusbx can be useful for libusb, and specifically
> because the two libraries share similar values in their API and many
> man-years worth of code in their implementation I try to participate
> also in libusbx discussion. The more participation the better, to
> simplify things a bit.
>
I see this as a good thing.
--
Xiaofan
------------------------------
Message: 7
Date: Wed, 2 May 2012 13:03:59 +0800
From: Xiaofan Chen <xiaof...@gmail.com>
Subject: [Libusbx-devel] Microsoft's view on the perceived WinUSB
limitations
To: libusb-de...@lists.sourceforge.net,
libusbx-devel@lists.sourceforge.net
Message-ID:
<cagjspud8cfwjy4vcuja7dttppft3mzpkp3nmn1mhl94xoic...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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 actual reset command to an USB device.
A1: it is a privileged operation. Even if the user was an admin this
can directly
effect other stacks in a composite device".
Q2: WinUSB cannot be used to set a device configuration that is
different from the
default one.
A2: windows as a whole from a windows provided class driver pov only
supports the
default config
Q3: WinUSB does not support multiple concurrent applications (as per the
MSDN documenation).
A3: correct. There is no way to know what is stateful and what is not. If you
want concurrent app access, layer a umdf driver stack on winusb
Q4: WinUSB does not support isochronous transfers.
A4: yup. Neither does kmdf natively. The market for isoch support is extremely
small, difficult to argue the cost benefit
Q5: When using interface control requests (LIBUSB_RECIPIENT_INTERFACE),
WinUSB overrides the low byte of wIndex with the destination interface.
Ref: http://www.lvr.com/forum/index.php?topic=331
A5: this is so you only target your interface on a composite device. Letting a
user mode stack manipulate a sibling interface is bad security and
encapsulation, no?
BTW, I have also posted this to libusb-win32 mailing list.
--
Xiaofan
------------------------------
------------------------------------------------------------------------------
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
End of libusbx-devel Digest, Vol 3, Issue 4
*******************************************------------------------------------------------------------------------------
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
