On 2/24/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Friday 24 February 2006 7:05 am, Andrew Fuller wrote: > > This patch is for the Dual USB Joypad [0925:8866] from Wisegroup. The > > HID_QUIRK_NOGET is necessary for it to respond to input, and the > > HID_QUIRK_MULTI_INPUT is necessary to have two js# nodes appear. > > > > This patch has been confirmed by two other people aside from myself, > > so I would like it included in the kernel at the next opportunity. > > Just so I'm clear on this ... the driver worked in previous form > with a workaround that added an extra device descriptor fetch, yes? > > That makes me wonder how many of the QUIRK_NOGET devices are the > same sort of bug in the peripheral hardware/firmware: something > leftover in the control processing that could be "flushed" by > some other control request, rather than needing to bypass that > part of driver init. I suppose I'll never know. > > - Dave
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 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? -Andrew ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
