2014/1/9 Nothing sckal...@vip.qq.com:
I can not find the conifigure file
Maybe that is because the real file name is configure and not conifigure?
The archive libusb-1.0.18-rc1.tar.bz2 _DO_ contain the configure file.
Of course the github repository do not contain the configure file. But
you
miguelfreitas, please stop trying to somehow propagate the EFAULT and recover
from it. Something is causing bad pointers and/or memory corruption, once that
happens any predictable behavior is off the table.
I will only accept a patch for this if it turns out the bad pointers are caused
by a
On 2014.01.09 06:30, Bent Bisballe Nyeng wrote:
How much difference will there be to libusbx-1.0.18 and libusb-1.0.18?
As far as developers are concerned, no difference.
What I mean is; will the merge simply be a copy of the current libusbx
code to the libusb repository
Yup. Just one extra
On Thu, Jan 9, 2014 at 2:41 PM, Pete Batard p...@akeo.ie wrote:
libusb.info
Pete, First congrats on the merge.
Small suggestion on this the new site:
What happened to the old site?
The old site is now obsolete. Please use *libusb.info http://libusb.info/*.
All of the libusb development has
exit from sync_transfer_wait_for_completion when libusb_handle_events_completed
failed
and libusb_cancel_transfer returns LIBUSB_ERROR_NOT_FOUND. this error is
returned when
urbs is not found in kernel (it was already dequeued from async_completed list),
therefore there is nothing to cancel. if
Thanks for the patch. We'll see what we can do to integrate it, but can you
tell us a bit more about the circumstances where this behaviour occurs, and how
easy or difficult it is to produce (i.e. do you see the infinite loop
consistently happening in an app, or is it a bit more random)?
/Pete
Unless we find something critical, I STRONGLY vote to delay it until after
1.0.18, even if it's doc.
As Murphy's day (yesterday) taught me, if there's anything that can go
wrong when duplicating work, it will go wrong. The github sudden breakage
[1], which you are aware of, and which thankfully
Hello all,
I have an application using libusb-win32 API and a device using libusb0.sys
driver. I wanted to check the possibility of using the newly released
libusb library in my application. So I just tried to open the device and
set the configurations.
The API can correctly identify the device,
If an EFAULT return from the kernel results in an infinite loop in
libusb(x):
It's not a matter of _recovering_ from the EFAULT. It's a matter of
whether libusb(x) should propagate it to the caller or not.
There is simply _no_ excuse not to propagate it.
Sarcasm on
Should we tell the kernel
On Fri, Jan 10, 2014 at 2:17 PM, Pradeepa Senanayake
pradeepa@gmail.com wrote:
Hello all,
I have an application using libusb-win32 API and a device using libusb0.sys
driver. I wanted to check the possibility of using the newly released libusb
library in my application. So I just tried to
no i did not change.
Best Regards,
Pradeepa Senanayake.
On Fri, Jan 10, 2014 at 12:42 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Jan 10, 2014 at 2:17 PM, Pradeepa Senanayake
pradeepa@gmail.com wrote:
Hello all,
I have an application using libusb-win32 API and a device using
So in that case, with this new release which I got through
http://libusb.info/ what are the compatible drivers?
Best Regards,
Pradeepa Senanayake.
On Fri, Jan 10, 2014 at 12:43 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Fri, Jan 10, 2014 at 3:12 PM, Xiaofan Chen xiaof...@gmail.com wrote:
12 matches
Mail list logo
