Distribution: all Hardware Environment: uhci/via Software Environment: all Problem Description: The following fix is not correct: Pete Zaitcev: o USB: fix hid-input problem with BTC keyboards /* * The Set_Idle request is supposed to affect only the * "Interrupt In" pipe. Unfortunately, buggy devices such as * the BTC keyboard (ID 046e:5303) the request also affects * Get_Report requests on the control pipe. In the worst * case, if the device was put on idle for an indefinite * amount of time (as we do below) and there are no input * events to report, the Get_Report requests will just hang * until we get a USB timeout. To avoid this, we temporarily * establish a minimal idle time of 1ms. This shouldn't hurt * bugfree devices and will cause a worst-case extra delay of * 1ms for buggy ones. */ What the code (same logic in 2.4.28) actually does, it sets idle to 1 (periodic interrupts on), does the 'get report', set idle to 0 (indeffnet, only new data interrupts). However according to HID 1.11 (should be the latest) 'HID Set_Idle Request' is required only for keyboards, for others it's optional. Since, as a result of the above fix, the last SETUP is the 'Set_Idle'. A Device that doesn't support that command returns STALL (correctly). As the there is no subsequent SETUP, it remains in STALL state and does not report anything (again that's correct behaviour). Possible fix would be to follow that request by some standard request that most likely is supported by all (even bugiest devices) (like 'standard Get_Status Request'), which would release the STALL state. As a side, the above fix does not help 'Logitech Inc. WingMan Strike Force 3D'. The 'Get_Report Request' still times out. I can see that the SETUP is submited correctly. Either there is a bug in Logitech device or the above is not correct way to make the device to produce interrutps. Steps to reproduce: Use any joystick that does not support 'Set_Idle Request'. I have plenty of debugging. If you want them, email me. I made also a patch to uhci-debug.c to see better what's going on. Would be usefull for building better trace for uhci. How is the current HID driver maintainer?
Created attachment 4152 [details] improved uhci debuging and tracing tools
Created attachment 4153 [details] exsample trace of the bug
Created attachment 4154 [details] trace of Logitech behaviour
Pete thinks this is an input driver problem.
Is this still an issue with 2.6.14-rc6 or greater? If so, please reopen this bug.