On Sat, 25 Feb 2006, Andrew Fuller wrote: > After your comment I decided to dig a bit deeper into the issue at > hand. Without marking this device as having any quirk, I've narrowed > down the issue to the call to usb_submit_urb at the end of the > hid_submit_ctrl function in hid-core.c. I tried some tracing to see > what the control values were... and found the troublesome one. > > The interesting part of the trace is as follows: > submitting ctrl urb: Get_Report wValue=0x0101 wIndex=0x0000 wLength=7values > submitting ctrl urb: Get_Report wValue=0x0101 wIndex=0x0000 wLength=7values > drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed > submitting ctrl urb: Get_Report wValue=0x0102 wIndex=0x0000 wLength=7values > > If I put a conditional return looking for wValue==0x0102, then the the > device works, and the tracing finishes after the submit_urb failed > line (so no further get_reports appear to be queued after the one of > wValue==0x0102). > > Perhaps the device cannot handle that specific request, or perhaps it > cannot handle that request after the previous one had failed. Then > again, why did that second one fail if the first didn't?
I rather doubt this line of investigation will prove very helpful. You'll probably find that the device works when you suppress the very same usb_submit_urb calls that the NOGET quirk prevents. > I tried looking at the USB spec for a definition of the values, > unfortunately they only seem to specify wValue meanings when the > 'type' portion of the RequestType is 0 (Standard). However, these > calls have 'type' set to 1 (Class) and wValue has different meanings > for different types. Do you (or anyone else reading this) know where > the values for wValue are defined for type Class? The high byte is the report type; 1 = Input. The low byte is the report ID number. The information in each report is listed in the device's HID descriptor and report descriptors. For more information, you want the "Device Class Definition for HID 1.11" document from http://www.usb.org/developers/hidpage/ You should also be able to see what the messages do by reading the source code. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
