On Fri, 15 Oct 2010, Florian Echtler wrote: > On Wed, 2010-10-13 at 13:33 -0400, Alan Stern wrote: > > On Wed, 13 Oct 2010, Florian Echtler wrote: > > > On Wed, 2010-10-13 at 10:07 -0400, Alan Stern wrote: > > > > On Wed, 13 Oct 2010, Florian Echtler wrote: > > > > > Interestingly, however, there's a > > > > > significant delay when loading the driver: > > > > > > > > > > [ 895.253903] ntrig 0003:1B96:0001.0003: hidraw2: USB HID v1.10 Device > > > > > [N-trig DuoSense] on usb-0000:00:1d.0-1.8/input0 > > > > > [ 895.254142] ntrig 0003:1B96:0001.0003: Firmware version: 4.8.15.20.7 > > > > > (2108 8fe2) > > > > > [ 895.255956] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c: > > > > > submitting ctrl urb: Get_Report wValue=0x0101 wIndex=0x0001 wLength=10 > > > > > [ 905.228517] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c: > > > > > timeout waiting for ctrl or out queue to clear > > > > > [ 905.228719] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c: > > > > > submitting ctrl urb: Get_Report wValue=0x0103 wIndex=0x0001 wLength=94 > > > > > [ 905.228732] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c: > > > > > usb_submit_urb(ctrl) failed > > > > > [ 905.228754] ntrig 0003:1B96:0001.0004: timeout initializing reports > > > > Just guessing, this may indicate that the device needs to have the > > > > HID_QUIRK_NOGET quirk. > > > I've tried "options usbhid quirks=0x1b96:0x0001:0x0008", but without any > > > noticeable effect... That certainly ought to prevent the Get-Report requests. You might want to add a debugging statement to the beginning of __usbhid_submit_report to see if the NOGET flag is set properly. > > Perhaps this is caused by the following lines near the end of > > ntrig_probe(), added by Stephane (commit 6549981bc): > > > > /* This is needed for devices with more recent firmware versions */ > > report = hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0x0a]; > > if (report) > > usbhid_submit_report(hdev, report, USB_DIR_OUT); > > > > You can see that this doesn't check for the NOGET quirk. > Thanks for the hint - that did the trick. I've commented this block out > and rebuilt the driver, with the result that everything seems to work > fine now. I have still added the NOGET quirk to usbhid - will check > later if this is actually necessary with the removed firmware check. > > A background question here: why should a report with USB_DIR_OUT check > for the NOGET quirk, though? Good point. You should compare traces captured with and without that block to see what effect it has. I couldn't see it in the Wireshark data. Either way, the NOGET flag is most likely necessary. > > usbmon might provide some helpful information. For example, why does > > the usb_submit_urb(ctrl) failure occur? > I've attached a Wireshark trace of loading the unpatched driver. Not > sure what to make of this... hope it helps. For me, usbmon output is a lot easier to read than the Wireshark display. See the instructions in Documentation/usb/usbmon.txt. It looks like there are several Get-Report requests in the Wireshark log. They don't come from hid-ntrig.c so they probably originate in usbhid/hid-core.c; the NOGET flag should prevent them. And those Get-Report requests are where everything started going wrong, so they certainly seem suspicious. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
