gmane.comp.lib.libusb.devel.general

Re: Do you need a product ID for your open source project?

Peter Stuge — 2012-05-25T21:58:47

I believe at91lib uses a compatible license. Worth checking.



It's of course not so nice to have different vidpid for the same
device doing the same thing using the same protocol because of
arbitrary restrictions imposed by an arbitrary vendor.

If there weren't so many small ARM controllers with USB I would be
using the third party USB stack for the USB PICs.

Note that it may be enough to have published schematics for the
hardware. I guess this may be provided by Microchip for the PIC
hardware and possibly also by Atmel for the AVR32 board. If the
situation is explained and the hardware documentation is referd
to in the mail to the usb-id< at > address then I'd expect that a pid
can still be acquired, even though the firmware comes with various
restrictions.


//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. Di

Re: interrupt transfer linux

Alan Stern — 2012-05-25T17:42:13

You need to use Reply-To-All.  Otherwise your message gets sent just to 
me, not to the mailing list.

On Fri, 25 May 2012, Fabian Weiss wrote:


I believe it is LIBUSB_ERROR_OVERFLOW.  You can call libusb_strerror() 
to find out.

In this case the overflow probably occurred because on line 60:

  r = libusb_interrupt_transfer(dev_handle, 0x83, buf, 10, &transferred, 100000); 

your program asked to receive 10 bytes but the device sent 42 bytes
(the endpoint's wMaxPacketSize).


Alan Stern


------------------------------------------------------------------------------
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/

Re: interrupt transfer linux

Alan Stern — 2012-05-25T14:52:25


Your program contains the following in line 48:

  r = libusb_claim_interface(dev_handle, 3); //claim interface 0 (the first) of device (mine had jsut 1)

How come the code refers to interface 3 whereas the comment refers to 
interface 0?

Your program contains the following in line 60:

  r = libusb_interrupt_transfer(dev_handle, 3, buf, 10, &transferred, 100000);

How come the code uses bEndpointAddress 3 instead of 0x83?


See above.

Alan Stern


------------------------------------------------------------------------------
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/

Re: interrupt transfers

Xiaofan Chen — 2012-05-25T09:51:35

On Wed, May 23, 2012 at 12:15 AM, John Stirling
<john.stirling< at >audiopartnership.com> wrote:

That kernel version is really very old. You may want to try
a newer version to see if that helps.

Re: interrupt transfer linux

Xiaofan Chen — 2012-05-25T09:45:24

Answered in libusbx mailing list as well.

You have to know the communication protocol of the device
in order to use libusb. If not, you have to do some reverser
engineering before you can use libusb to communicate with
the device.

Re: Do you need a product ID for your open source project?

Xiaofan Chen — 2012-05-25T09:43:23

Nice one.

It does not seem to help on the 32bit AVR libusbK benchmark firmware
since it is based on the Atmel Firmware Framework...

It does not apply to the libusbK PIC benchmark firmware either
since it is based Microchip's USB Stack (Microchip Application
library). But we've got a free PID (Microchip VID) thanks to the
support of Microchip.

interrupt transfer linux

Fabian Weiss — 2012-05-23T14:38:58

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/

RE: interrupt transfers

John Stirling — 2012-05-22T16:15:13

if
appearing

Ah, okay.  If you know that both packets are getting sent on the 
bus, have you checked that the data toggle values are set correctly?  
An incorrect data toggle will cause a packet to be ignored by the host 
controller.

If you're running under Linux, you can get further information by using
usbmon (see Documentation/usb/usbmon.txt in the kernel source) and by 
turning on the usbfs_snoop module parameter for usbcore.  The first 
will show whether the kernel receives the second packet correctly, and 
the second will show whether the information is getting sent back to 
libusb.


[John Stirling] 
Yes, I'm running linux. 2.6.21, on a Samsung s3c2412 (arm based)

I haven't checked the toggle values. I'll have a look. Thanks for the
suggestion.

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 <a href="http://www.audiopartnership.com/AP-disclaimer.html">Disclaimer</a>  for important noti

RE: interrupt transfers

Alan Stern — 2012-05-22T14:51:16


Ah, okay.  If you know that both packets are getting sent on the 
bus, have you checked that the data toggle values are set correctly?  
An incorrect data toggle will cause a packet to be ignored by the host 
controller.

If you're running under Linux, you can get further information by using
usbmon (see Documentation/usb/usbmon.txt in the kernel source) and by 
turning on the usbfs_snoop module parameter for usbcore.  The first 
will show whether the kernel receives the second packet correctly, and 
the second will show whether the information is getting sent back to 
libusb.


Oh, you're right.  Sorry, my mistake -- I didn't look very carefully.

Alan Stern


------------------------------------------------------------------------------
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.ac

RE: interrupt transfers

John Stirling — 2012-05-22T13:09:47

On Mon, 21 May 2012, Peter Stuge wrote:

pipe
that

I don't understand why this is a problem in the first place.

Why does there have to be an outstanding transfer at all times?  If the
device wants to send or receive some data on an interrupt endpoint but
the host isn't ready, the device should simply wait until the host _is_
ready.  It shouldn't throw away the data.

[John Stirling] 
If I stack up the transfers the tx/rx sequence is a lot quicker than if
i just have one transfer. It's not essential, just seemed better.

The data is being sent across the bus correctly. It's just not appearing
in the rx callback. The 2nd packet is appearing. It's as if it has
overwritten the first packet. I haven't dug any further than that.


If there _are_ going to be several transfers outstanding then why isn't 
the async API being used?  The idea with multiple transfers is that 
each time one of them completes, you submit a new one.  That can't be
done with synchronous transfers (unless you use a separate thread for 
ea

Re: interrupt transfers

Peter Stuge — 2012-05-22T12:57:18


Can you give more details about your environment? Which operating
system, what have you considered with regard to kernel drivers, and
so on? Also if you use libusb-1.0 directly or HIDAPI, and if libusb
then a note about why would be good.

libusb is not really suited for HID class communication. HIDAPI is
significantly better.


//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/

RE: interrupt transfers

John Stirling — 2012-05-22T12:53:00


Do you really need the timeout?  Usually, a timeout on an interrupt pipe
is just an escape hatch, in case something goes horribly wrong.  In that
case, you could set it to a very long interval that was unlikely to
occur in real life.

[John Stirling] 

Setting the timeout to eg 15 seconds results works ok for a few
transfers but then seems to occasionally stick (for about 15 seconds)
and then delivers the data via the interrupt callback 15 seconds later
than it is actually observed on the USB trace.

I initially tried with timeout=0. That seems to result in a few
successful transfers followed by nothing. Possibly this is the same
problem as above.

I'm guessing above is not expected behaviour.

Going back to my original example with 10 transfers stacked up I have
double checked that they have not timed out at the point where the
problem occurs. The USB analyser shows two packets successfully
transferred on HID report 1. There is a 1ms gap between the two. I'm
only seeing data from the 2nd packet appear in

Do you need a product ID for your open source project?

Peter Stuge — 2012-05-21T21:42:27

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/

Re: interrupt transfers

Alan Stern — 2012-05-21T18:47:36


I don't understand why this is a problem in the first place.

Why does there have to be an outstanding transfer at all times?  If the
device wants to send or receive some data on an interrupt endpoint but
the host isn't ready, the device should simply wait until the host _is_
ready.  It shouldn't throw away the data.

If there _are_ going to be several transfers outstanding then why isn't 
the async API being used?  The idea with multiple transfers is that 
each time one of them completes, you submit a new one.  That can't be
done with synchronous transfers (unless you use a separate thread for 
each one, which seems like overkill).  The async API doesn't include 
timeouts -- you just cancel a transfer whenever you want.

Alan Stern


------------------------------------------------------------------------------
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

Re: interrupt transfers

Akos Vandra — 2012-05-21T18:31:36

Also if your app might be used from within a virtual machine, the
latency can skyrocket. I could get my app working only if my timeout
were in the 500ms range. Usually they completed around 100ms, but
sometimes it got as high as 500ms.

Regards,
  Ákos

On 21 May 2012 20:23, Peter Stuge <peter< at >stuge.se> wrote:

------------------------------------------------------------------------------
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/

Re: interrupt transfers

Peter Stuge — 2012-05-21T18:23:15

I'd recommend using a minimum of 10+bInterval ms timeout for
interrupt transfers if you want to make sure that they will
not time out under normal circumstances.


//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/

Re: interrupt transfers

Tim Roberts — 2012-05-21T17:41:48

That's quite possible.


Do you really need the timeout?  Usually, a timeout on an interrupt pipe
is just an escape hatch, in case something goes horribly wrong.  In that
case, you could set it to a very long interval that was unlikely to
occur in real life.

interrupt transfers

John Stirling — 2012-05-21T16:14:47

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

Re: [PATCH] libusb-compat-0.1 examples: Link only with../libusb/libusb.la and not with -lusb

Xiaofan Chen — 2012-05-21T01:29:12

Ping...

Re: Controlling and reading a usb radio

Hans de Goede — 2012-05-15T08:26:09

Hi,

On 05/14/2012 11:45 PM, Deron wrote:

Good!


I've attached a kernel patch, if you build a kernel with this patch you should no
longer need the unbind and new_id magic.


Test the patch.


I appreciate the offer, but I already have bought an si470x based usb radio
stick myself, it should arrive at my home soon-ish. The reason I bought one
is because of the poor state of userspace support for radio devices under
Linux, which I hope to one day improve...

What would be great (if you think it would be fun to do) would be if you
could work on a decent userspace app for radios. IE something like
gnome-radio ported to gnome/gtk3 and taught that most modern radio's
don't have analog output, but that it needs to read the data from
an alsa device and loopback it into another alsa device.

For the alsa loopback part, see the code in the tv part of xawtv which
already knows how to figure out which alsa node belongs to a v4l2 node,
and how to loop back. Another project would be separating that code
from the tv part

Re: Query: Getting Hot Plug/Unplug notification for USB device

madhav chauhan — 2012-05-15T08:23:26

Thanks Garret for the information. I will watch the same.

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/