http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19932 <pre>Hi, I managed to build a java application that uses the LibusbJava wrapper on Windows, but my intention was to run it on the Raspberry Pi. I've been trying for a while, but I can't seem to set up the Raspberry for using it. I'm no linux expert, so this is pretty hard for me. I'm trying to use the LibusbJava wrapper over libusb-0.1.12. Any help would be greatly appreciated! Cheers. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d_______________________________________________ libusb-devel mailing list libusb-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusb-devel </pre> Gustavo Belisário 2013-05-19T18:05:50 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19931 <pre> It means the status stage of the control-IN request did not complete. Alan Stern ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d </pre> Alan Stern 2013-05-18T16:17:17 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19930 <pre> The relevant section of a usbmon log is here: f331c980 2304680318 S Co:1:015:0 s 40 c2 0000 0000 0002 2 = 0100 f331c980 2304680651 C Co:1:015:0 0 2 &gt; f3289b00 2306726435 S Ci:1:015:0 s c0 c0 0000 0000 001b 27 &lt; f3289b00 2316726545 C Ci:1:015:0 -2 27 = 0a0af40a 7baeca0a 00000000 02fc6241 00000000 00000000 4c5e00 f246f000 2316780939 S Co:1:015:0 s 40 c2 0000 0001 0002 2 = 0200 f246f000 2316781415 C Co:1:015:0 0 2 &gt; This shows a 10-second gap between the submission of the control pipe read request for 27 bytes and its completion. The completion has an -ENOENT error, which just means the request was killed while still in progress. However, the 27-byte dump here IS the correct information, and it's current -- it's not left over in the buffer. So, it would appear that the response was received, but the request was not completed. What does that mean? What would it be waiting for? </pre> Tim Roberts 2013-05-17T23:14:01 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19929 <pre>Done, I've tried, we now see Thank you very much Federico ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d </pre> Federico Manzan 2013-05-17T15:14:26 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19928 <pre> You can ask for this yourself. Just send an email to the linux-usb&lt; at &gt;vger.kernel.org mailing list. Alan Stern ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d </pre> Alan Stern 2013-05-17T13:58:56 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19927 <pre>But is not a BUG of libusb-darwin. With USB2.0 the max isochronous size can be 3x1024 byte every 125us With USB3.0 the max isochronous size can be 1x1024 * mult * bust every 125us if mult=3, with burst=2 libusb can allocate and submit a isocronous, with bust=3 and more the fuction libusb_submit_transfer() return a errors: libusb: 0.000000 error [submit_iso_transfer] submiturb failed error -1 errno=22 but is not a bug of libusb, but a limitation of linux kernel in the file of kernel 3.8 and 3.9 drivers/usb/core/devio.c: ... for (totlen = u = 0; u &lt; uurb-&gt;number_of_packets; u++) { /* arbitrary limit, * sufficient for USB 2.0 high-bandwidth iso */ if (isopkt[u].length &gt; 8192) { ret = -EINVAL; goto error; } totlen += isopkt[u].length; } ... I have increased, compiled, tested and work correct. Now for USB 3.0 the "arbitrary limit" needed to be incremented If somebody can ask to increase this va</pre> Federico Manzan 2013-05-16T21:01:38 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19926 <pre>#131: Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9 ---------------------+-------------------------------------- Reporter: dl1ksv | Owner: stuge Type: defect | Status: accepted Milestone: 1.0.10 | Component: libusb-1.0 Linux backend Resolution: | Keywords: Blocked By: | Blocks: ---------------------+-------------------------------------- Comment (by hansdegoede): Replying to [comment:21 jleveque]: &gt; Hans, &gt; &gt; Thank you for the quick reply. I will try building libusbx with your patch and testing it, but as this problem has only occurred (to my knowledge) once in the past year, I don't know how to reproduce it, and because of the infrequency, I honestly won't know if it fixed my issue, therefore I won't be able to provide you any feedback. Out of curiosity, has this patch been approved/submitted to libusbx upstream? Submitted yes, approved not yet, it is currently waiting for the Windows maintainer to take a closer look. </pre> libusb Trac 2013-05-16T18:18:06 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19925 <pre>#131: Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9 ---------------------+-------------------------------------- Reporter: dl1ksv | Owner: stuge Type: defect | Status: accepted Milestone: 1.0.10 | Component: libusb-1.0 Linux backend Resolution: | Keywords: Blocked By: | Blocks: ---------------------+-------------------------------------- Comment (by jleveque): Hans, Thank you for the quick reply. I will try building libusbx with your patch and testing it, but as this problem has only occurred (to my knowledge) once in the past year, I don't know how to reproduce it, and because of the infrequency, I honestly won't know if it fixed my issue, therefore I won't be able to provide you any feedback. Out of curiosity, has this patch been approved/submitted to libusbx upstream? </pre> libusb Trac 2013-05-16T15:56:41 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19924 <pre>#131: Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9 ---------------------+-------------------------------------- Reporter: dl1ksv | Owner: stuge Type: defect | Status: accepted Milestone: 1.0.10 | Component: libusb-1.0 Linux backend Resolution: | Keywords: Blocked By: | Blocks: ---------------------+-------------------------------------- Comment (by hansdegoede): Replying to [comment:19 jleveque]: &gt; Just checking in to see if any progress has been made with regards to this bug. Today I experienced a crash in this exact location running a proprietary program that calls libusb-1.0 directly (i.e. no HIDAPI). This is the first time I have seen this crash and we have been compiling multiple projects against libusb-1.0.9 since April 2012, so I'm not quite sure if I can reproduce it to help out. Any updates? Thanks in advance. Hi, I think this may be a variation on the issue explained in, and fixed by, this patch: https://sour</pre> libusb Trac 2013-05-16T07:53:11 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19923 <pre>#131: Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9 ---------------------+-------------------------------------- Reporter: dl1ksv | Owner: stuge Type: defect | Status: accepted Milestone: 1.0.10 | Component: libusb-1.0 Linux backend Resolution: | Keywords: Blocked By: | Blocks: ---------------------+-------------------------------------- Comment (by jleveque): Just checking in to see if any progress has been made with regards to this bug. Today I experienced a crash in this exact location running a proprietary program that calls libusb-1.0 directly (i.e. no HIDAPI). This is the first time I have seen this crash and we have been compiling multiple projects against libusb-1.0.9 since April 2012, so I'm not quite sure if I can reproduce it to help out. Any updates? Thanks in advance. </pre> libusb Trac 2013-05-15T22:48:13 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19922 <pre>#173: libusb_get_max_iso_packet_size() with USB3.0, return the USB2.0 value --------------------+---------------------------------------- Reporter: manzo | Owner: Type: defect | Status: new Milestone: | Component: libusb-1.0 Darwin backend Keywords: | Blocked By: Blocks: | --------------------+---------------------------------------- libusb_get_max_iso_packet_size() not consider the libusb_ss_endpoint_companion_descriptor and return the size in the USB2.0 descriptor, for understand in the USB3.0 the isochronous work with burst I propose this patch: {{{ diff --git a/libusb/core.c b/libusb/core.c index 90c4247..7043ee3 100644 --- a/libusb/core.c +++ b/libusb/core.c &lt; at &gt;&lt; at &gt; -864,7 +864,7 &lt; at &gt;&lt; at &gt; int API_EXPORTED libusb_get_max_iso_packet_size(libusb_device *dev, const struct libusb_endpoint_descriptor *ep; enum libusb_transfer_type ep_type; uint16_t val; - int r; + int r,s; r = libusb_get_active_confi</pre> libusb Trac 2013-05-15T19:24:25 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19921 <pre>2013/5/14 Tim Roberts &lt;timr&lt; at &gt;probo.com&gt;: 2-3(?) years ago I had a USB problem on an ARM based board. I do not remember if I got timeout errors. The problem was solved just by upgrading the Linux kernel on the board. I also do not remember the Linux versions used before and after the fix. Bye -- Dr. Ludovic Rousseau ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d </pre> Ludovic Rousseau 2013-05-14T16:17:41 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19920 <pre>We have a client reporting a strange problem. The details are sketchy, but I wanted to ask here in case it was familiar to anyone. The product is a somewhat unusual camera designed for astronomical use (they are particularly good at extracting photons in very low-light situations). It is not UVC. The USB chip is a Cypress FX2. Transfers are done over a bulk pipe, with lots of register and status access via vendor commands. My client has sold these products for more than 10 years, in Windows (WinUSB) and in Linux (libusb), with very few problems. Now, they have one client using their camera on a small board computer running Linux 2.6.32. What they're reporting is that, every 4 to 6 days, they have a vendor command time out (LIBUSB_ERROR_TIMEOUT). After the timeout, further actions on the control pipe get LIBUSB_ERROR_PIPE. It's necessary to close and re-open the device in order to recover. The control pipe request has a timeout of 10 seconds, and we see that 10 second gap in the app logs. We don'</pre> Tim Roberts 2013-05-13T23:11:03 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19919 <pre>#125: libusb_kernel_driver_active() and _detach() are racy --------------------------+------------------------ Reporter: stuge | Owner: Type: enhancement | Status: new Milestone: | Component: libusb-1.1 Resolution: | Keywords: Blocked By: | Blocks: --------------------------+------------------------ Comment (by hansdegoede): Hi, Replying to [comment:2 hjelmn]: &gt; Does Hans's commit found &lt; at &gt; https://github.com/hjelmn/libusb- darwin/commit/774cfa0405fe646436eab3b846ece171d1ab8eae fix the race? No that does not fix it I'm afraid. Alan is correct in stating that fixing this race needs a kernel change. Which is why I've written a kernel patch to allow to do these things in a race free manner, see: http://permalink.gmane.org/gmane.linux.usb.general/69725 This patch is upstream now, but libusb still needs to be modified to use it. This requires adding a new API for this, as the old API is inherently racy. I've this on my </pre> libusb Trac 2013-05-08T15:52:16 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19918 <pre>#125: libusb_kernel_driver_active() and _detach() are racy --------------------------+------------------------ Reporter: stuge | Owner: Type: enhancement | Status: new Milestone: | Component: libusb-1.1 Resolution: | Keywords: Blocked By: | Blocks: --------------------------+------------------------ Comment (by hjelmn): Does Hans's commit found &lt; at &gt; https://github.com/hjelmn/libusb- darwin/commit/774cfa0405fe646436eab3b846ece171d1ab8eae fix the race? </pre> libusb Trac 2013-05-08T15:05:45 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19917 <pre>#162: libusb_alloc_transfer vulnerable to integer overflow/underflow ---------------------+------------------------ Reporter: meacer | Owner: Type: defect | Status: new Milestone: 1.0.16 | Component: libusb-1.0 Resolution: | Keywords: security Blocked By: | Blocks: ---------------------+------------------------ Changes (by hjelmn): * milestone: =&gt; 1.0.16 Comment: I don't see a problem with including this patch. Can you apply this patch to either libusb.git or libusb-darwin.git (clone https://github.com/hjelmn /libusb-darwin.git) and post a patch generated with git format-patch? </pre> libusb Trac 2013-05-08T15:01:17 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19916 <pre>#149: Correction for libusb-compat's pkg-config file with static linking ----------------------------------+------------------------------- Reporter: brad | Owner: stuge Type: defect | Status: assigned Milestone: libusb-compat 0.1.5 | Component: libusb-compat-0.1 Resolution: | Keywords: Blocked By: | Blocks: ----------------------------------+------------------------------- Changes (by hjelmn): * milestone: =&gt; libusb-compat 0.1.5 </pre> libusb Trac 2013-05-08T14:51:04 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19915 <pre>#130: libusb-compat-0.1 does not call libusb_exit() ----------------------------------+------------------------------- Reporter: xiaofan | Owner: stuge Type: defect | Status: assigned Milestone: libusb-compat 0.1.5 | Component: libusb-compat-0.1 Resolution: | Keywords: libusb-compat Blocked By: | Blocks: ----------------------------------+------------------------------- Changes (by hjelmn): * milestone: =&gt; libusb-compat 0.1.5 </pre> libusb Trac 2013-05-08T14:50:32 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19914 <pre>#161: Build with automake-1.13 broken ----------------------------------+------------------------------- Reporter: xiaofan | Owner: stuge Type: defect | Status: assigned Milestone: libusb-compat 0.1.5 | Component: libusb-compat-0.1 Resolution: | Keywords: Blocked By: | Blocks: ----------------------------------+------------------------------- Changes (by hjelmn): * milestone: =&gt; libusb-compat 0.1.5 </pre> libusb Trac 2013-05-08T14:50:11 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19913 <pre> This is almost certainly a problem in the kernel's host controller driver. One trick for working around the problem is to start the isochronous transfer (i.e., the audio data stream) first, then start the interrupt transfer (i.e., the keyboard/mouse) afterward. For example, you could detach the kernel driver for the keyboard interface, then start the microphone data transfer, and then reattach the keyboard's kernel driver. Alan Stern ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may </pre> Alan Stern 2013-05-08T14:33:06 http://permalink.gmane.org/gmane.comp.lib.libusb.devel.general/19912 <pre> Bus 002 Device 023: ID 0b0e:0412 GN Netcom Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0b0e GN Netcom idProduct 0x0412 bcdDevice 1.01 iManufacturer 0 iProduct 2 Jabra SPEAK 410 USB iSerial 3 0023781F9228x010100 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 230 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterf</pre> kumar gokhare 2013-05-07T22:36:07 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.libusb.devel.general