gmane.comp.lib.libusb.devel.general http://blog.gmane.org/gmane.comp.lib.libusb.devel.general hourly 1 1901-01-01T00:00+00:00 Gmane http://gmane.org/img/gmane-25t.png http://gmane.org libusbk type of streaming API for libusb? http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18493 <pre>http://libusbk.sourceforge.net/UsbK3/group__stmk.html http://libusbk.sourceforge.net/UsbK3/xfer-stream_8c-example.html It seems to me the above streaming API can be a good addition to libusb-1.0. How do you like the idea? </pre> Xiaofan Chen 2012-05-26T09:41:23 interrupt transfer linux http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18482 <pre>Hello everyone :) I try to communicate with an USB device: http://nopaste.info/bc655859b3.html I want to read the 42 bytes of bEndpointAddress 0x83 EP 3 IN. Therefore I installed libusb under my Linux and wrote this little programm: http://nopaste.info/98c35ab092.html I dont understand why it doesnt work, so I am asking you. My output is: Device Opened Claimed Interface libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=2 read Error: -1 Data read: Released Interface Can somebody tell my what I am doing wrong? Thx in advance, fabske :) ------------------------------------------------------------------------------ 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/ </pre> Fabian Weiss 2012-05-23T14:38:58 Do you need a product ID for your open source project? http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18476 <pre>You can ask Openmoko for one: http://wiki.openmoko.org/wiki/USB_Product_IDs#Open_registry_for_community_.2F_homebrew_USB_Product_IDs //Peter ------------------------------------------------------------------------------ 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/ </pre> Peter Stuge 2012-05-21T21:42:27 interrupt transfers http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18471 <pre>Hi, I'm having an issue with occasional lost interrupt transfers. On a USB analyser I can see the problem occurs when two interrupt transfers come in fairly close to each other (approx 1ms gap). Currently I am stacking up several (10) interrupt transfer requests at initialisation and then just resubmitting them every time I get a callback. Setup - #define HID_RX_BUFFER_SIZE 512 static void vRequestHIDData(int iIndex) { libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle]; unsigned int uiHIDEndpoint = [poUSBDevice uiGetHIDEndpoint]; struct libusb_transfer *ptTransfer = g_atHIDRxTransfers[iIndex].ptTransfer; u8 *pu8Buffer = g_atHIDRxTransfers[iIndex].pu8Data; // Reload the transfer libusb_fill_interrupt_transfer(ptTransfer, // transfer ptDeviceHandle, // dev_handle uiHIDEndpoint, // endpoint pu8Buffer, // buffer HID_RX_BUFFER_SIZE, // length vHIDRxCallback, // callback (void *)iIndex, // user_data 500 // timeout ); libusb_submit_transfer(ptTransfer); } Resubmission: static void vHIDRxCallback(struct libusb_transfer *ptTransfer) { int iLength = ptTransfer-&gt;actual_length; int iIndex = (int)ptTransfer-&gt;user_data; if (ptTransfer-&gt;status != LIBUSB_TRANSFER_TIMED_OUT) { vLOG_STATIC_FUNC_VA("### HID RX (%d) l=%d s=%d ###", iIndex, iLength, ptTransfer-&gt;status); if (bLOG_IsLoggingEnabledHere()) vUTL_DumpHex(ptTransfer-&gt;buffer, iLength); } // Send it on to main app thread write(iWriteFD, ptTransfer-&gt;buffer, iLength); // and set up to receive more HID data libusb_submit_transfer(ptTransfer); } If I set different timeouts for each transfer i can see the previously missing transfers. eg static void vRequestHIDData(int iIndex) { libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle]; unsigned int uiHIDEndpoint = [poUSBDevice uiGetHIDEndpoint]; struct libusb_transfer *ptTransfer = g_atHIDRxTransfers[iIndex].ptTransfer; u8 *pu8Buffer = g_atHIDRxTransfers[iIndex].pu8Data; // Reload the transfer libusb_fill_interrupt_transfer(ptTransfer, // transfer ptDeviceHandle, // dev_handle uiHIDEndpoint, // endpoint pu8Buffer, // buffer HID_RX_BUFFER_SIZE, // length vHIDRxCallback, // callback (void *)iIndex, // user_data (100*iIndex) // timeout ); libusb_submit_transfer(ptTransfer); } I suspect my initial attempty was failing due to all 10 transfers timing out at approx the same time and not being resubmitted quick enough ? Is there an example somewhere showing interrupt transfers stacked up and resubmitted ? Although setting different timeouts is getting me past this problem I suspect I might need to recalculate the timeout on each resubmission to ensure there are a certain number outstanding at all times ? Thanks, John Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK Reg No. 2953313 This e-mail is confidential and for the addressee only. Please refer to &lt;a href="http://www.audiopartnership.com/AP-disclaimer.html"&gt;Disclaimer&lt;/a&gt; for important notices.------------------------------------------------------------------------------ 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/_______________________________________________ libusb-devel mailing list libusb-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusb-devel </pre> John Stirling 2012-05-21T16:14:47 [PATCH] libusb-compat-0.1 examples: Link only with../libusb/libusb.la and not with -lusb http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18461 <pre>commit e01ea627d1c5caac9492870b315353173e7b8a61 Author: Xiaofan Chen &lt;xiaofanc&lt; at &gt;gmail.com&gt; Date: Sun May 13 19:50:38 2012 +0800 modified: examples/Makefile.am This is similar to the following libusb-1.0 patch. http://git.libusb.org/?p=libusb.git;a=commitdiff;h=93b0e09d53ed1d177631af918 Previous _LDFLAGS included both the freshly built libusb in ../libusb and -lusb, where libtool would usually resolve the latter to an already-installed libusb library in the system. The extra reference to a second libusb library may cause failures to build examples on some platforms and is wrong. diff --git a/examples/Makefile.am b/examples/Makefile.am index 3023b58..5292cef 100644 --- a/examples/Makefile.am +++ b/examples/Makefile.am &lt; at &gt;&lt; at &gt; -2,8 +2,8 &lt; at &gt;&lt; at &gt; INCLUDES = -I$(top_srcdir)/libusb noinst_PROGRAMS = lsusb testlibusb lsusb_SOURCES = lsusb.c -lsusb_LDADD = ../libusb/libusb.la -lusb +lsusb_LDADD = ../libusb/libusb.la testlibusb_SOURCES = testlibusb.c -testlibusb_LDADD = ../libusb/libusb.la -lusb +testlibusb_LDADD = ../libusb/libusb.la </pre> Xiaofan Chen 2012-05-13T11:53:24 [pete< at >akeo.ie: Re: [Libusbx-devel] [PATCH] Add topology calls] http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18456 <pre>Pete removed the libusb list as recipient in his reply, so I'm forwarding. ----- Forwarded message from Pete Batard &lt;pete&lt; at &gt;akeo.ie&gt; ----- To: libusbx-devel&lt; at &gt;lists.sourceforge.net Subject: Re: [Libusbx-devel] [PATCH] Add topology calls Date: Fri, 11 May 2012 19:26:24 +0100 On 2012.05.11 19:08, Peter Stuge wrote: And you'll be free to take risks and live on the edge, for what is really a minor detail not worth spending much time on, when/if you carry the API in libusb. Your suggestion has been heard, and, as ever, I'm puzzled as to why you're trying to blow such a minor API item out of proportion, just to attempt to get "your way" in a project that had to fork precisely because of this behaviour. Well, if people vote to have get_parent to be removed from the public API because they see it too limiting, and we don't get user requests otherwise in the meantime, I don't have a problem keeping it private and reviewing its introduction to the public API once we have hotplug and an overhauled enum. But that only applies to get_parent. Regards, /Pete ----- End forwarded message ----- ------------------------------------------------------------------------------ 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/ </pre> Peter Stuge 2012-05-11T18:29:30 [peter< at >stuge.se: Re: [Libusbx-devel] [PATCH] Add topology calls] http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18453 <pre>Pete proposed some new topology APIs in libusbx, and I sent some comments and questions about them to their mailing list. I'm forwarding to the libusb-devel list in order to hear from more people - maybe you can answer my questions or have other thoughts on the proposal. Thanks! //Peter ----- Forwarded message from Peter Stuge &lt;peter&lt; at &gt;stuge.se&gt; ----- To: libusbx-devel&lt; at &gt;lists.sourceforge.net Subject: Re: [Libusbx-devel] [PATCH] Add topology calls Date: Fri, 11 May 2012 17:48:17 +0200 Pete Batard wrote: I think the proposed API could be simplified. There's a hard upper limit on the path length (7 ports including the HC) so I would suggest to drop the path_len input parameter and document that path must be uint8_t [7] or longer. Please explain this comment in more detail? Does it refer to the libusb_device refcounting? Are all devices refcounted by their children? //Peter ----- End forwarded message ----- ------------------------------------------------------------------------------ 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/ </pre> Peter Stuge 2012-05-11T15:50:33 Query: Getting Hot Plug/Unplug notification for USB device http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18444 <pre>Hi All, I am trying to get  notification whenever any USB device hot plugged in or plugged out. I used  LIBUSB API: libusb_set_pollfd_notifiers() in the following manner but i get event only whenever any device plugged out not for plug in. /*Code Snippet*/ libusb_context *ctx retval = libusb_init(&amp;ctx); libusb_pollfd_added_cb device_AddedCalBack; libusb_pollfd_removed_cb deviceRemovedCallBack;  device_AddedCalBack = &amp;sample_libusb_pollfd_added_cb;  deviceRemovedCallBack = &amp;sample_libusb_pollfd_removed_cb;  //register hot plug and unplug events.  if(retval ==0){ dbg_printf(TRC_VERBOSE, TRC_FLAGS_MUX, "****Calling libusb_set_pollfd_notifiers \n");  libusb_set_pollfd_notifiers(ctx, device_AddedCalBack, deviceRemovedCallBack, (void*)ctx); dbg_printf(TRC_VERBOSE, TRC_FLAGS_MUX, "****Call libusb_set_pollfd_notifiers returned %d \n",retval); Regards, Madhav ------------------------------------------------------------------------------ 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/ </pre> madhav chauhan 2012-05-10T07:15:03 isochronous transfers http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18435 <pre>Hi, I'm attempting to use libusb-1.0 to stream audio data from an isochronous endpoint : Endpoint Descriptor (Audio): ------------------------------ Value Valuename 0x09 bLength 0x05 bDescriptorType 0x83 bEndpointAddress (In-Endpoint) 0x01 bmAttributes Transfer Type: Isochronous-Transfer Synchronization Type: None Usage Type: Data 0x00C0 wMaxPacketSize (192 Bytes) 0x01 bInterval 0x00 bRefresh 0x00 bSynchAddress Hex dump: 0x09 0x05 0x83 0x01 0xC0 0x00 0x01 0x00 0x00 (I'm using http://git.tuxfamily.org/microdiausp/microdiauserspace.git as an example of how to drive isochronous transfers.) As per above example, two transfers are set up via uiAudioEndpoint = 0x83; iMaxAudioPackets = 10; libusb_device *ptDevice = [poUSBDevice ptGetDevice]; iMaxIsoPacketSize = libusb_get_max_iso_packet_size(ptDevice, uiAudioEndpoint); iAudioBufferLength = iMaxIsoPacketSize * iMaxAudioPackets; int i; for (i=0; i&lt;NUM_TRANSFERS; i++) { atTransfers[i].ptAudioTransfer = libusb_alloc_transfer(iMaxAudioPackets); atTransfers[i].pu8AudioData = g_malloc(iAudioBufferLength); } Transfers are filled in and submitted as follows - static void vRequestAudioData(int iIndex) { libusb_device_handle *ptDeviceHandle = [poUSBDevice ptGetDeviceHandle]; uiAudioEndpoint = 0x83; vLOG_STATIC_FUNC_VA("h=%p uiAudioEndpoint=0x%02x", ptDeviceHandle, uiAudioEndpoint); struct libusb_transfer *ptAudioTransfer = atTransfers[iIndex].ptAudioTransfer; u8 *pu8AudioData = atTransfers[iIndex].pu8AudioData; // Reload the transfer libusb_fill_iso_transfer(ptAudioTransfer, // transfer ptDeviceHandle, // dev_handle uiAudioEndpoint, // endpoint pu8AudioData, // buffer iAudioBufferLength, // length iMaxAudioPackets, // num_iso_packets vAudioTransferCallback, // callback (void *)iIndex, // user_data 500 // timeout ); libusb_set_iso_packet_lengths(ptAudioTransfer, iMaxIsoPacketSize); ptAudioTransfer-&gt;num_iso_packets = iMaxAudioPackets; ptAudioTransfer-&gt;type |= LIBUSB_TRANSFER_TYPE_ISOCHRONOUS; libusb_submit_transfer(ptAudioTransfer); } Then libusb kicked via eg while (1) { libusb_handle_events(ptContext); } Audio transfers are handled as follows - static void vAudioTransferCallback(struct libusb_transfer *ptTransfer) { int iCount = 0; int iIndex = (int)ptTransfer-&gt;user_data; int i; for (i=0; i&lt;iMaxAudioPackets; i++) { int iStatus = ptTransfer-&gt;iso_packet_desc[i].status; int iLength = ptTransfer-&gt;iso_packet_desc[i].actual_length; if (iStatus == 0) { const u8 *d = libusb_get_iso_packet_buffer_simple(ptTransfer, i); vLOG_STATIC_FUNC_VA("## AUDIO %d [%d] s=%d %d %d ## %02x %02x %02x %02x", iIndex, i, iStatus, iCount, iAudioDataCount, d[0],d[1],d[2],d[3]); iCount += iLength; if (1) { const u8 *pu8Data = libusb_get_iso_packet_buffer_simple(ptTransfer, i); vWriteData(pu8Data, iLength); } } } iAudioDataCount += iCount; libusb_submit_transfer(ptTransfer); } I am seeing some (presumably) real audio data received but also blocks of silence. In all cases, the first two iso packets report actual_length=0 (status = 0). The other packets all seem to report status = 0 and actual_length=192. But there quite a bit of silence along with the real audio data. Any suggestions as to what I'm doing wrong ? Note if I enable the kernel usb audio driver I can extract audio data correctly from this device (not via libusb). Sample debug output showing the received iso packets [1970-01-01 01:43:40.210950] APK: 6 [1970-01-01 01:43:40.213641] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 11520 ## 00 00 00 00 [1970-01-01 01:43:40.216951] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 11520 ## 00 00 00 00 [1970-01-01 01:43:40.219735] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [1] s=0 192 11520 ## 00 00 00 00 [1970-01-01 01:43:40.223220] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [2] s=0 384 11520 ## 67 fa 87 fc [1970-01-01 01:43:40.226307] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [3] s=0 576 11520 ## b0 05 18 04 [1970-01-01 01:43:40.229425] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [4] s=0 768 11520 ## 8c 01 8d 0a [1970-01-01 01:43:40.232478] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [5] s=0 960 11520 ## fa 10 68 07 [1970-01-01 01:43:40.235584] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 11520 ## 37 fc a0 f6 [1970-01-01 01:43:40.238448] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 11520 ## 67 10 fb 11 [1970-01-01 01:43:40.241528] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 11520 ## fe 3e e4 2d [1970-01-01 01:43:40.244246] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 11520 ## ab 27 0a 0c [1970-01-01 01:43:40.248378] APK: 7 [1970-01-01 01:43:40.251457] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 13440 ## 00 00 00 00 [1970-01-01 01:43:40.254397] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 13440 ## 00 00 00 00 [1970-01-01 01:43:40.257499] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [1] s=0 192 13440 ## 00 00 00 00 [1970-01-01 01:43:40.260553] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [2] s=0 384 13440 ## 14 17 2a 13 [1970-01-01 01:43:40.263494] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [3] s=0 576 13440 ## 00 00 00 00 [1970-01-01 01:43:40.266423] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [4] s=0 768 13440 ## 08 cc 7e e7 [1970-01-01 01:43:40.270542] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [5] s=0 960 13440 ## 2d 02 08 02 [1970-01-01 01:43:40.273383] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 13440 ## cc 33 8c 17 [1970-01-01 01:43:40.276251] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 13440 ## fe fb 58 01 [1970-01-01 01:43:40.279282] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 13440 ## c0 1e fc 22 [1970-01-01 01:43:40.282025] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 13440 ## f5 2d db 1b [1970-01-01 01:43:40.285341] APK: 8 [1970-01-01 01:43:40.287917] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 15360 ## 00 00 00 00 [1970-01-01 01:43:40.290592] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 15360 ## 00 00 00 00 [1970-01-01 01:43:40.293534] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [1] s=0 192 15360 ## 00 00 00 00 [1970-01-01 01:43:40.297206] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [2] s=0 384 15360 ## 00 00 00 00 [1970-01-01 01:43:40.299787] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [3] s=0 576 15360 ## 00 00 00 00 [1970-01-01 01:43:40.302547] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [4] s=0 768 15360 ## 00 00 00 00 [1970-01-01 01:43:40.305560] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [5] s=0 960 15360 ## 00 00 00 00 [1970-01-01 01:43:40.308276] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 15360 ## 00 00 00 00 [1970-01-01 01:43:40.311370] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 15360 ## 00 00 00 00 [1970-01-01 01:43:40.314361] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 15360 ## 00 00 00 00 [1970-01-01 01:43:40.317197] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 15360 ## 00 00 00 00 [1970-01-01 01:43:40.320896] APK: 9 [1970-01-01 01:43:40.323373] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 17280 ## 00 00 00 00 [1970-01-01 01:43:40.326469] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 17280 ## 00 00 00 00 [1970-01-01 01:43:40.329211] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [1] s=0 192 17280 ## 00 00 00 00 [1970-01-01 01:43:40.332293] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [2] s=0 384 17280 ## 00 00 00 00 [1970-01-01 01:43:40.335149] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [3] s=0 576 17280 ## 00 00 00 00 [1970-01-01 01:43:40.338327] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [4] s=0 768 17280 ## 00 00 00 00 [1970-01-01 01:43:40.341078] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [5] s=0 960 17280 ## 00 00 00 00 [1970-01-01 01:43:40.344239] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 17280 ## 00 00 00 00 [1970-01-01 01:43:40.347355] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 17280 ## 00 00 00 00 [1970-01-01 01:43:40.350426] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 17280 ## 00 00 00 00 [1970-01-01 01:43:40.353044] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 17280 ## 00 00 00 00 [1970-01-01 01:43:40.356274] APK: 10 [1970-01-01 01:43:40.358936] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 19200 ## 00 00 00 00 [1970-01-01 01:43:40.361895] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 19200 ## 00 00 00 00 [1970-01-01 01:43:40.364625] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [1] s=0 192 19200 ## 00 00 00 00 [1970-01-01 01:43:40.367423] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [2] s=0 384 19200 ## 00 00 00 00 [1970-01-01 01:43:40.370733] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [3] s=0 576 19200 ## 00 00 00 00 [1970-01-01 01:43:40.373669] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [4] s=0 768 19200 ## 00 00 00 00 [1970-01-01 01:43:40.376641] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [5] s=0 960 19200 ## 00 00 00 00 [1970-01-01 01:43:40.379476] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 19200 ## 00 00 00 00 [1970-01-01 01:43:40.382556] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 19200 ## 00 00 00 00 [1970-01-01 01:43:40.385597] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 19200 ## 00 00 00 00 [1970-01-01 01:43:40.388249] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 19200 ## 00 00 00 00 [1970-01-01 01:43:40.391605] APK: 11 [1970-01-01 01:43:40.394268] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 21120 ## 00 00 00 00 [1970-01-01 01:43:40.397703] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [0] s=0 0 21120 ## 00 00 00 00 [1970-01-01 01:43:40.400550] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [1] s=0 192 21120 ## 00 00 00 00 [1970-01-01 01:43:40.403441] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [2] s=0 384 21120 ## 00 00 00 00 [1970-01-01 01:43:40.406244] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [3] s=0 576 21120 ## 00 00 00 00 [1970-01-01 01:43:40.409378] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [4] s=0 768 21120 ## 00 00 00 00 [1970-01-01 01:43:40.412248] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [5] s=0 960 21120 ## 00 00 00 00 [1970-01-01 01:43:40.415340] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [6] s=0 1152 21120 ## 00 00 00 00 [1970-01-01 01:43:40.418073] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [7] s=0 1344 21120 ## 00 00 00 00 [1970-01-01 01:43:40.421518] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [8] s=0 1536 21120 ## 00 00 00 00 [1970-01-01 01:43:40.424226] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 1 [9] s=0 1728 21120 ## 00 00 00 00 [1970-01-01 01:43:40.427576] APK: 12 [1970-01-01 01:43:40.430343] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 23040 ## 00 00 00 00 [1970-01-01 01:43:40.433348] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [0] s=0 0 23040 ## 00 00 00 00 [1970-01-01 01:43:40.436195] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [1] s=0 192 23040 ## 00 00 00 00 [1970-01-01 01:43:40.439210] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [2] s=0 384 23040 ## 00 00 00 00 [1970-01-01 01:43:40.441925] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [3] s=0 576 23040 ## ab f9 ed ef [1970-01-01 01:43:40.444603] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [4] s=0 768 23040 ## 00 00 00 00 [1970-01-01 01:43:40.448085] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [5] s=0 960 23040 ## 23 e5 19 ef [1970-01-01 01:43:40.451235] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [6] s=0 1152 23040 ## 07 0a 82 f5 [1970-01-01 01:43:40.453757] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [7] s=0 1344 23040 ## a7 06 84 02 [1970-01-01 01:43:40.456527] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [8] s=0 1536 23040 ## c7 ed 0e 00 [1970-01-01 01:43:40.459447] APK: &lt;&gt;vAudioTransferCallback ## AUDIO 0 [9] s=0 1728 23040 ## a4 03 b4 04 Thanks John Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK Reg No. 2953313 This e-mail is confidential and for the addressee only. Please refer to &lt;a href="http://www.audiopartnership.com/AP-disclaimer.html"&gt;Disclaimer&lt;/a&gt; for important notices.------------------------------------------------------------------------------ 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/_______________________________________________ libusb-devel mailing list libusb-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusb-devel </pre> John Stirling 2012-05-08T16:03:14 openbsd_usb.c warnings under NetBSD http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18428 <pre>Hi Martin, Maybe you want to take a look at the following warnings. os/openbsd_usb.c: In function '_sync_control_transfer': os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer will break strict-aliasing rules localhost$ ./autogen.sh libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/pkg/share/aclocal/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from... /usr/pkg/share/aclocal/libtool.m4:4158: _LT_LINKER_SHLIBS is expanded from... /usr/pkg/share/aclocal/libtool.m4:5233: _LT_LANG_C_CONFIG is expanded from... /usr/pkg/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/pkg/share/aclocal/libtool.m4:67: LT_INIT is expanded from... /usr/pkg/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/pkg/share/aclocal/libtool.m4:4158: _LT_LINKER_SHLIBS is expanded from... /usr/pkg/share/aclocal/libtool.m4:5233: _LT_LANG_C_CONFIG is expanded from... /usr/pkg/share/aclocal/libtool.m4:138: _LT_SETUP is expanded from... /usr/pkg/share/aclocal/libtool.m4:67: LT_INIT is expanded from... /usr/pkg/share/aclocal/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1038: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:4174: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5249: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:160: _LT_SETUP is expanded from... aclocal.m4:89: LT_INIT is expanded from... aclocal.m4:124: AC_PROG_LIBTOOL is expanded from... configure.ac:39: the top level configure.ac:42: installing `./compile' configure.ac:39: installing `./config.guess' configure.ac:39: installing `./config.sub' configure.ac:29: installing `./install-sh' configure.ac:29: installing `./missing' examples/Makefile.am: installing `./depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... i386-unknown-netbsdelf6.0. checking host system type... i386-unknown-netbsdelf6.0. checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so|_pic\.a)$ checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for windres... no checking for inline... inline checking whether gcc and cc understand -c and -o together... yes checking operating system... NetBSD (using OpenBSD backend) checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/timerfd.h usability... no checking sys/timerfd.h presence... no checking for sys/timerfd.h... no checking whether TFD_NONBLOCK is declared... no checking whether to use timerfd for timing... no (header not available) checking for struct timespec... yes checking for sigaction... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for gettimeofday... yes configure: creating ./config.status config.status: creating libusb-1.0.pc config.status: creating Makefile config.status: creating libusb/Makefile config.status: creating examples/Makefile config.status: creating doc/Makefile config.status: creating doc/doxygen.cfg config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands localhost$ make make all-recursive Making all in libusb CC libusb_1_0_la-core.lo CC libusb_1_0_la-descriptor.lo CC libusb_1_0_la-io.lo CC libusb_1_0_la-sync.lo CC libusb_1_0_la-openbsd_usb.lo os/openbsd_usb.c: In function '_sync_control_transfer': os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer will break strict-aliasing rules CC libusb_1_0_la-threads_posix.lo CCLD libusb-1.0.la Making all in doc Making all in examples CC listdevs.o CCLD listdevs CC dpfp.o CCLD dpfp CC dpfp_threaded-dpfp_threaded.o CCLD dpfp_threaded localhost$ uname -a NetBSD localhost.localdomain 6.0_BETA NetBSD 6.0_BETA (GENERIC) i386 localhost$ gcc -v Using built-in specs. COLLECT_GCC=gcc Target: i486--netbsdelf Configured with: /usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure --target=i486--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit --with-arch=i486 --with-tune=nocona --with-mpc=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-mpfr=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-gmp=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd5.99.56 --host=i486--netbsdelf Thread model: posix gcc version 4.5.3 (NetBSD nb2 20110806) </pre> Xiaofan Chen 2012-05-08T10:21:27 Polling file descriptors for synchronous transfers http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18420 <pre>Hello I can't seem to find a solution to this anywhere, but it seems strange that no one would have encountered this before. Please don't get mad if this stuff is old hat: I am writing a single threaded application that has a poll/select loop. I don't need asynchronous USB transfers at all, but I do need to poll the file descriptors associated with the USB device. This does not seem possible, or is it? Some pseudo code to give you some idea what's going on before the first poll: libusb_init(NULL) libusb_device_handle * handle = discover_my_device() // discover, open &amp; claim the device libusb_bulk_transfer(handle, endpoint OUT, message, ...) // the device will write an answer back Polling details: short poll_usb_fds(short events, int timeout) { int i, count = 0; struct pollfd * fds; const struct libusb_pollfd ** list = libusb_get_pollfds(NULL); if (list == NULL) { printf("could not list pollable file descriptors\n"); return -1; } for (i = 0; list[i] != NULL; i++) { count++; printf("may poll fd=%i events=0x%x\n", list[i]-&gt;fd, list[i]-&gt;events); } fds = calloc(count, sizeof(struct pollfd)); if (fds == NULL) { printf("calloc() failed\n"); return -2; } for (i = 0; i &lt; count; i++) { fds[i].fd = list[i]-&gt;fd; fds[i].events = list[i]-&gt;events &amp; events; } free(list); short r = poll(fds, count, timeout); printf("poll() = %i\n", r); for (i = 0; i &lt; count; i++) { printf("fd=%i, revents=0x%x\n", fds[i].fd, fds[i].events); } free(fds); return r; } I call poll_usb_fds(POLLIN, 10000), and it NEVER returns before the timeout. The OS poll() always returns zero, even though .revents=POLLIN for 2 of 3 file descriptors. What is going on? The actual transfers work just fine, of course. System details: $ uname -a Linux seldlx0540 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:12:07 UTC 2012 x86_64 GNU/Linux $ dpkg -s libusb-1.0-0 Package: libusb-1.0-0 Status: install ok installed Priority: optional Section: libs Installed-Size: 124 Maintainer: Ubuntu Developers &lt;ubuntu-devel-discuss&lt; at &gt;lists.ubuntu.com&gt; Architecture: amd64 Source: libusb-1.0 Version: 2:1.0.6-1 Depends: libc6 (&gt;= 2.8) Description: userspace USB programming library Library for programming USB applications without the knowledge of Linux kernel internals. Original-Maintainer: Aurelien Jarno &lt;aurel32&lt; at &gt;debian.org&gt; Homepage: http://www.linux-usb.org/ Please help. This is a blocking issue for me :-( BR / Mysingen -- View this message in context: http://libusb.6.n5.nabble.com/Polling-file-descriptors-for-synchronous-transfers-tp5674722p5674722.html Sent from the LibUSB Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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/ </pre> Mysingen 2012-04-29T21:53:25 Controlling and reading a usb radio http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18413 <pre>Hello, I hope this is an appropriate things to post here. I have an AlertFM usb radio that is "windows only" that I want to use on my Ubuntu server. The plan is to set it up to listen for EAS warnings on our local radio station. (We live a long way from civilization and don't always have the TV on). If I can get the audio stream, I can do the rest easy enough (I've got that part written and tested using recordings of EAS audio messages). Anyway, I have a windows computer and captured some channel changing data using their software, and digging around I found this software which actually recommends hidapi for HID devices. No problem, I have that installed along with libusb and I think I even have it changing channels (one report sets the channel, and another reads back the current channel. Still an input report I can't seem to grab which gives signal strength data etc, but I could live without that.) What I don't have now is the audio stream. I'm not very familiar with USB, so this is a really basic question, but what do I do to read that data? I'm guessing that hidapi won't be able to read that data, and somehow need to mix in calls with libusb? I've not had much luck finding sample applications for hidapi, and if someone could just nudge me in the correct direction I would appreciate it or even basic info on USB that would fluff out my knowledge without have to read an encyclopedia on USB. Thanks! Deron ------------------------------------------------------------------------------ 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/ </pre> Deron 2012-05-07T15:10:07 Test, please ignore http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18409 <pre> //Peter ------------------------------------------------------------------------------ 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/ </pre> Peter Stuge 2012-05-07T09:47:36 Tips to use FreeBSD libusb wrapper http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18404 <pre>1) It may be necessary to create your own libusb.pc and libusb-1.0.pc since FreeBSD does not ship them. Ref: http://lists.freebsd.org/pipermail/freebsd-usb/2011-July/010470.html &gt;cat /usr/local/libdata/pkgconfig/libusb.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libusb Description: USB access library Version: 0.1 Libs: -L${libdir} -lusb Cflags: -I${includedir} ~ &gt;cat /usr/local/libdata/pkgconfig/libusb-1.0.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libusb Description: USB access library Version: 1.0.1 Libs: -L${libdir} -lusb Cflags: -I${includedir} 2) FreeBSD does not have libusb-1.0.so and libusb-1.0.a, only libusb.so and libusb.a. It may be necessary to create the symbolic link. 3) If the stock FreeBSD libusb is missing some function, try the svn head version. </pre> Xiaofan Chen 2012-05-06T13:50:17 FreeBSD libusb missing libusb_get_descriptor() http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18403 <pre>http://libusb.sourceforge.net/api-1.0/group__desc.html libusb_get_descriptor() is in libusb-1.0. But I do not see this in FreeBSD's libusb-1.0 wrapper. http://svnweb.freebsd.org/base/head/lib/libusb/libusb.h?view=markup Maybe it is a good idea to add this one. Thanks. </pre> Xiaofan Chen 2012-05-06T13:38:50 libusb-compat auto-tools warnings http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18400 <pre>I am using automake 1.12 and autoconf 2.69 and there are quite some warnings for libusb-compat. Not so sure how to fix them though since I know very little of auto-tools. mymacmini:libusb-compat-0.1 xiaofanc$ ./autogen.sh glibtoolize: putting auxiliary files in `.'. glibtoolize: copying file `./ltmain.sh' glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. glibtoolize: copying file `m4/libtool.m4' glibtoolize: copying file `m4/ltoptions.m4' glibtoolize: copying file `m4/ltsugar.m4' glibtoolize: copying file `m4/ltversion.m4' glibtoolize: copying file `m4/lt~obsolete.m4' /usr/local/share/aclocal/log4shib.m4:7: warning: underquoted definition of AM_PATH_LOG4SHIB /usr/local/share/aclocal/log4shib.m4:7: run info Automake 'Extending aclocal' /usr/local/share/aclocal/log4shib.m4:7: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2598: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2608: AC_COMPILE_IFELSE is expanded from... configure.ac:55: the top level configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2598: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2608: AC_COMPILE_IFELSE is expanded from... configure.ac:55: the top level configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2598: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2608: AC_COMPILE_IFELSE is expanded from... configure.ac:55: the top level configure.ac:55: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2598: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2608: AC_COMPILE_IFELSE is expanded from... configure.ac:55: the top level checking for a BSD-compatible install... /usr/local/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... i386-apple-darwin11.3.0 checking host system type... i386-apple-darwin11.3.0 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm checking the name lister (/usr/bin/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert i386-apple-darwin11.3.0 file names to i386-apple-darwin11.3.0 format... func_convert_file_noop checking how to convert i386-apple-darwin11.3.0 file names to toolchain format... func_convert_file_noop checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver &lt; at &gt;FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm output from gcc object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for -force_load linker flag... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common -DPIC checking if gcc PIC flag -fno-common -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin11.3.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for inline... inline checking whether gcc and cc understand -c and -o together... yes checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for LIBUSB_1_0... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating libusb.pc config.status: creating libusb-config config.status: creating Makefile config.status: creating libusb/Makefile config.status: creating examples/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default commands </pre> Xiaofan Chen 2012-05-06T00:31:15 [libusb] #130: libusb-compat-0.1 does not call libusb_exit() http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18394 <pre>#130: libusb-compat-0.1 does not call libusb_exit() --------------------------------+-------------------------- Reporter: xiaofan | Owner: Type: defect | Status: new Component: libusb-compat-0.1 | Keywords: libusb-compat Blocked By: | Blocks: --------------------------------+-------------------------- There is a potential problem in the libusb-compat layer because libusb-1.0 requires a call to libusb_exit(). However, libusb_exit() is never called by the compat layer even though libusb_init() is used. http://git.libusb.org/?p=libusb-compat-0.1.git;a=blob;f=libusb/core.c;js=1 Also ref here which shows that libusb_exit() is really necessary. http://libusb.6.n5.nabble.com/quot-memory-leak-quot-debug-message-after- libusb-close-and-upon-application-exit-td5581475.html </pre> libusb Trac 2012-05-05T13:48:18 bulktransfer and control transfer mixed http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18385 <pre>Hi I am rewriting exisitng code to control a cheap dongle for DAB, to be used in conjunction with my sdr software. The code uses libusb for interfacing to the dongle and it seems I am managing to get some data out of it. The question is: Can I mix receiving a 2 Mbyte data stream from the dongle (using the usb bulk mode) with sending a control command (e.g. to switch to another frequency) or should I stop the incoming datastream first, then give my command and then resume the datastream? (The datastream is just a stream of samples, so logically there is no real harm done when I have to stop it for a while, however, resuming the stream complicates the software somewhat). Thanks in advance jan </pre> jan van katwijk 2012-05-03T14:03:52 libusb-compat-0.1 does not call libusb_exit() http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18380 <pre>There is a potential problem in the libusb-compat layer because libusb-1.0 requires a call to libusb_exit().  However, libusb_exit() is never called by the compat layer even though libusb_init() is used. http://git.libusb.org/?p=libusb-compat-0.1.git;a=blob;f=libusb/core.c;js=1 Also ref here which shows that libusb_exit() is really necessary. http://libusb.6.n5.nabble.com/quot-memory-leak-quot-debug-message-after-libusb-close-and-upon-application-exit-td5581475.html A potential solution is add a new API usb_exit(). </pre> Xiaofan Chen 2012-05-02T23:25:30 HIDAPI FreeBSD Patch http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18363 <pre>Hi, Here's a re-organized patch adding FreeBSD support to the current HIDAPI git version. I moved the libusb code out of the linux/ directory and created a libusb/ directory which applies for both Linux and FreeBSD versions of hidapi/libusb. Now that Linux and FreeBSD share code, it will be easier to maintain. Also, this version has improved character encoding over the last version. Let me know how it works for you. If so, I'll commit it. Thanks! Alan. ------------------------------------------------------------------------------ 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/_______________________________________________ libusb-devel mailing list libusb-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusb-devel </pre> Alan Ott 2012-05-01T19:58:38 Questions about hotpluging USB devices under MS-Windows http://comments.gmane.org/gmane.comp.lib.libusb.devel.general/18362 <pre>I have written a Libusb 1.0 "driver" for a USB device. The driver uses a 'daemon' process to interface multiple client programs to the device and I can launch this daemon process under Linux via either the (old) hotplug mechanism or the (newer) udev mechanism. The driver itself (and the daemon) is mostly cross-platform (there are a few bits here and there that need cleaning up) and I am wondering what sort of mechanism(s) are available under MS-Windows to launch the daemon process upon plugging in the USB device (and killing it off once the device is removed). Under Linux is it just a matter of dropping control files and scripts into the proper places (eg in /etc/udev/rules.d and /lib/udev/). How does this work under MS-Windows? I don't do development work under MS-Windows -- the code is all cross-built on my Linux system. </pre> Robert Heller 2012-05-01T16:50:04 Search Engine Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.libusb.devel.general