Re: [Libusb-devel] Missing Reports

[Frank T. <fr...@fr...>]

Alan Stern <stern <at> rowland.harvard.edu> writes:

> 
> On Sat, 25 Jul 2009, Frank Tkalcevic wrote:
> 
> > I am having a problem with missing interrupt reports in my application.
> > 
> > I am using libusb-1.0.2 to access a HID device (I'm testing with a 
Logitech 
> > Dual Action gamepad).  I can tell I am missing reports, because quite 
> > regularly it appears a button is stuck down.  If I look in my application 
> > debug, I can see that the last report included the key down bit, but no 
> > following report to say the key has been released.
> > 
> > My original application used libusb-0.1.12 because I wanted it to work on 
> > WIN32 too.  The application created a background thread for the USB 
> > processing.  In this thread, I'd loop around forever calling 
> > usb_interrupt_read with a 50msec timeout.  If I received a message I'd 
process 
> > it, then continue waiting for the next message.
> > 
> > Because this wasn't working, I suspected I was receiving interrupts while 
I 
> > wasn't waiting in a usb_interrupt_read.
> 
> That can't happen.  If you don't ask for a transfer (interrupt or
> other) then it won't occur.
> 
> However what _could_ happen is that the device could drop or otherwise 
> lose a report if your program doesn't transfer it in time.



Thanks for the reply.

I've managed to get my program to work reliably by increasing the timeout on 
the reads.  The lower the timeout, the more often I see the problem.  Is it 
possible the timeout is terminating the low level poll half way through a 
transfer?  I've looked through the linux usb driver code, but couldn't quite 
see what happens when the timeout occurs.  If I'm looking in the right place, 
it appears to just kill the outstanding URB.

Anyway, I now have multiple read transfers queued, set with 0x7FFFFFFF 
timeout.  In the callback, I store the report in the queue so it can be 
processed by another thread, then resubmit the completed read.  My main loop 
calls libusb_handle_events_timeout() with a 50ms timeout so I can check to see 
if there are messages to be sent to the USB device.  

With an almost infinite timeout, is there any point queuing multiple read 
requests?  The only slow down will be in my "add report to queue" code.  Can 
another report be received while I'm processing the first callback?  That is, 
is the driver still polling my device while I am processing the callback?  
Will the next queued read transfer receive this message?

Thanks,
Frank