gmane.comp.lib.libusb.devel.general

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

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.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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
each one, which seems like overkill). The async API doesn't include
timeouts -- you just cancel a transfer whenever you want.

[John Stirling]
I am using the async API. There are timeouts included in that as far as
I'm aware. Or am I missing something ?

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

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 the callback. The index
of the transfer is as expected (ie one greater than the last rx
transfer). It's like the 2nd packet has just overwritten the 1st.

If I repeat the test several times I am occasionally seeing the first
packet. I can't see any pattern to this yet.

Any suggestions ?

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 security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

                                 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->actual_length;
  int iIndex = (int)ptTransfer->user_data;

  if (ptTransfer->status != LIBUSB_TRANSFER_TIMED_OUT)
  {
    vLOG_STATIC_FUNC_VA("### HID RX (%d) l=%d s=%d ###", iIndex,
iLength, ptTransfer->status);
    if (bLOG_IsLoggingEnabledHere())
      vUTL_DumpHex(ptTransfer->buffer, iLength);
  }

  // Send it on to main app thread
  write(iWriteFD, ptTransfer->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 <a href="http://www.audiopartnership.com/AP-disclaimer.html">Disclaimer</a>  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< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

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 of xawtv and also make the xawtv radio app use it :)

If you want to donate me some hardware, I'm always looking for *old*
usb webcams to complete my collection (which I've for testing purposes
as I maintain a lot of usb webcam drivers). Chances are that whatever
you've I already have, so if you've an old cam you consider donating,
please first plug it in and do an lsusb, no use in shipping me a cam I
already have, and I already have about a 100 different models :)

Regards,

Hans
------------------------------------------------------------------------------
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< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

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/

Re: Controlling and reading a usb radio

Deron — 2012-05-14T21:45:16


I just used the URL as reference thinking it was the latest. I actually 
installed the program with apt-get install radio as I recall, and it 
seems to be old as well. Compiling the latest requires X11 which is a 
bit crazy for a server. I'm going to strip out the frequency change 
commands and see if I can get it to work...


.........

IT WORKS!!!

With the following (roughly) commands, I can make it work:

nano /etc/modprobe.d/radio.conf
add: options radio-usb-si470x space=0 band=0 de=0

cd /sys/bus/usb/drivers/usbhid
echo '4-1:1.2' > unbind
modprobe radio-usb-si470x
cd /sys/bus/usb/drivers/radio-si470x
echo '0x12cf 0x7111' > new_id

/dev/radio0 now exists and responds to proper commands. I can record 
with arecord -D "plughw:CARD=Radio,DEV=0" -f cd >audio.raw


So what can I do to make this permanent so as to survive resets of the 
server?

Can I do anything to help get this added to future releases?

And Hans, I owe you an AlertFM device :-) Would it be of any use to you? 
The device also supports some new US EAS like system, but it is not in 
my area (yet?) so no idea what would be required to make that work. Just 
happy to have the radio working properly now!

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/

Re: Controlling and reading a usb radio

Hans de Goede — 2012-05-14T08:15:59

Hi,

On 05/13/2012 06:01 PM, Deron wrote:

Ah, you're using an old version of xawtv which uses the no longer
supported v4l1 API, there is a newer version here, hopefully its
radio.c version will work better:
http://git.linuxtv.org/xawtv3.git

Regards,

Hans

------------------------------------------------------------------------------
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: Controlling and reading a usb radio

Chuck Cook — 2012-05-13T16:09:30

The chip that is being controlled is by SIlicaon labs
http://www.silabs.com/pages/Silabs-Search.aspx?q=si470x

On 05/13/2012 12:01 PM, Deron 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: Controlling and reading a usb radio

Deron — 2012-05-13T16:01:36


I was so hopeful! However, it made no difference. I even then tried 
setting space=0 and de=0, to no avail.

My attempts at a custom frequency changing program will generate pops in 
the audio output when changing the frequency, but the audio is silent. 
The radio program 
(http://www.cs.fsu.edu/~baker/devices/lxr/http/source/xawtv-3.95/console/radio.c) 
seems to enable the radio as when it is started the audio goes from 
silent to static, but I get the error "VIDIOCGAUDIO: Invalid argument" 
twice to console and changing the frequency does not generate any change 
in audio output. No pop, no change to static.


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/

Re: Controlling and reading a usb radio

Vincent Pelletier — 2012-05-13T12:31:13

Le dimanche 13 mai 2012 11:17:16, Vincent Pelletier a écrit :

And I was wrong.
The solution to this problem is to use "fm -T forever on" so "fm" keeps the 
device opened - otherwise, tuner is put to sleep but sound is not muted, 
resulting in static noise.

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

Xiaofan Chen — 2012-05-13T11:53:24

commit e01ea627d1c5caac9492870b315353173e7b8a61
Author: Xiaofan Chen <xiaofanc< at >gmail.com>
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
< at >< at > -2,8 +2,8 < at >< at > 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

Re: Controlling and reading a usb radio

Vincent Pelletier — 2012-05-13T09:17:16

Le dimanche 13 mai 2012 06:29:44, Deron a écrit :

FWIW, I have a similar experience with a radio part on a PCI tv card. When I 
enable FM tuner and loop the card's audio dev to speakers, I get static-ish 
noise... Until I switch the FM off, at which point I get perfect audio until 
some buffer runs out of data (ie, half a second, by hear).
I suspect there is a bug in some ring buffer access, where writing would 
overwrite not-read-yet data, or where updating write pointer would interfere 
with read pointer. But I'm not sure where to look.