| Hi Don,
Just curious, but are the items in question relative or absolute in the descriptor? If absolute, only a value change will cause the element to be added to the queue.
- Rob
On Jul 4, 2005, at 3:27 PM, Don Clark wrote: I have a bunch of HID devices that all use Cypress USB chips, and all support the same vendor-defined command-response protocol – my code issues an 8-byte command using SetReport specifying kIOHIDReportTypeFeature, then looks for a response (usually one 8-byte Interrupt In report). It looks for the response by calling GetNextEvent() from a queue that was pre-established – if the data isn’t there yet (underrun) the code waits for 20 msecs, then tries GetNextEvent() again. It will do this loop up to 16 times if the data doesn’t become available in this loop. Up until Tiger this worked pretty well.
Suddenly I am seeing behavior where my driver will never see data from some of my devices. I issue the command but the retry loop on the queue eventually exits with nothing but underruns. Some of the devices continue to work well. The devices that don’t work in this scenario work fine on a Windows machine (and I believe work fine on Panther, I’ll have to re-try this with my Firewire drive tomorrow).
The really strange part of this is that I hooked up an Ellisys USB logger device so that I can see the actual USB traffic. What I see is the OUT report going to the device, and the Interrupt IN report coming from the device with the proper data being transferred. But that data never appears on the queue as described above. Any ideas about where it’s going, or why it isn’t being passed along? I installed the latest debug IOUSBFamily driver and ran USB Prober, but unless it logs at level 7 there isn’t any data, and level 7 produces a HUGE amount of data – I don’t see anything in this report that jumps out at me.
Don Clark
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
