Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USB HID device misbehaving on Tiger

Title: Re: USB HID device misbehaving on Tiger
Hi Rob,

Last year we went through this and I added a kext that overrides one method in IOUSBHIDDriver, newReportDescriptor(), that sets the Input report to be Relative, as the hardware HID descriptor specifies this to be Absolute.  The kext is loaded, and shows up in USB Prober on the IORegistry page for my devices.  Just for fun I unloaded the kext and tried, and got the same result.  In the past, when I first added this kext, it was only needed in the context of one command that I issue to the device that causes it to respond with eight 8-byte reports – in that scenario it’s easy for one report to be identical to the preceding one and get thrown away.  

But even if this kext had not been running, this is the first I/O with this device after the open(), so the report should not be thrown away – it can’t be a duplicate of the predecessor as there was no predecessor.  Also, the code is uniform in that there is no difference in the sequence of events getting to this first command – this I/O always works on one device but never on another one.  

I could provide several files that might help, if you had time to look at them.  One is my own application’s log, that shows the command being issued and the underrun being encountered.  That same log file has a good sequence in it as well, with the other device.  Another file I’ve captured is an excerpt from the USB Prober probe report, showing both the device that fails and the one that works.  Another file is the USB Prober logger report -  the moment I cleared the log, got my application ready to execute the first command, then started the USB Prober logging and executed my command, then stopped USB Prober’s logging.  There is a ton of stuff in there even though.  In addition I could provide the Ellisys logs, but they would have to come to you as screen shots or hard copy of some sort.  I have a pair here with me that show the traffic – I could fax them to you, scan them and email them along.  Alternatively, if you have the Ellisys software I could re-capture the logs and send them tomorrow.

Thanks Rob.

/Don





On 7/4/05 4:26 PM, "Rob Yepez" <email@hidden> wrote:

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


This email sent to email@hidden <mailto:email@hidden> 


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.