Bug 3821 - 2.6.x USB HID driver problems
2.6.x USB HID driver problems
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 normal
Assigned To: Vojtech Pavlik
:
Depends on:
Blocks: USB
  Show dependency treegraph
 
Reported: 2004-11-26 10:58 UTC by Pekka Sarnila
Modified: 2005-08-18 21:40 UTC (History)
0 users

See Also:
Kernel Version: 2.6.9
Tree: Mainline
Regression: ---


Attachments
improved uhci debuging and tracing tools (3.43 KB, patch)
2004-11-26 11:00 UTC, Pekka Sarnila
Details | Diff
exsample trace of the bug (4.97 KB, text/plain)
2004-11-26 11:02 UTC, Pekka Sarnila
Details
trace of Logitech behaviour (6.89 KB, text/plain)
2004-11-26 11:03 UTC, Pekka Sarnila
Details

Description Pekka Sarnila 2004-11-26 10:58:42 UTC
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?
Comment 1 Pekka Sarnila 2004-11-26 11:00:55 UTC
Created attachment 4152 [details]
improved uhci debuging and tracing tools
Comment 2 Pekka Sarnila 2004-11-26 11:02:51 UTC
Created attachment 4153 [details]
exsample trace of the bug
Comment 3 Pekka Sarnila 2004-11-26 11:03:33 UTC
Created attachment 4154 [details]
trace of Logitech behaviour
Comment 4 Andrew Morton 2004-11-29 17:57:25 UTC
Pete thinks this is an input driver problem.
Comment 5 Greg Kroah-Hartman 2005-08-18 21:40:26 UTC
Is this still an issue with 2.6.14-rc6 or greater?  If so, please reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.