Description of problem: The force feedback module (hid-pidff) in the kernel does not detect the Microsoft Force Feedback 2 joystick correctly. How reproducible: Always Steps to Reproduce: 1. Plug in joystick. Actual results: The kernel reports 0 simultaneous effects detected. Expected results: Something more than 0. Additional info: The kernel outputs the following when the device is plugged. kernel: usb 4-2: New USB device found, idVendor=045e, idProduct=001b kernel: usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb 4-2: Product: SideWinder Force Feedback 2 Joystick kernel: usb 4-2: Manufacturer: Microsoft kernel: input: Microsoft SideWinder Force Feedback 2 Joystick as /devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.0/input/input5 kernel: hid-generic 0003:045E:001B.0001: device reports 0 simultaneous effects kernel: hid-generic 0003:045E:001B.0001: pid_block_load failed 60 times kernel: hid-generic 0003:045E:001B.0001: upload request failed kernel: hid-generic 0003:045E:001B.0001: input,hidraw0: USB HID v1.00 Joystick [Microsoft SideWinder Force Feedback 2 Joystick] on usb-0000:00:12 Also, when trying to use fftest, I get: Force feedback test program. HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES Device /dev/input/by-path/pci-0000:00:12.0-usb-0:2:1.0-event-joystick opened Features: * Absolute axes: X, Y, RZ, Throttle, Hat 0 X, Hat 0 Y, [63 00 03 00 00 00 00 00 ] * Relative axes: [00 00 ] * Force feedback effects types: Constant, Periodic, Ramp, Spring, Friction, Damper, Inertia, Gain, Force feedback periodic effects: Square, Triangle, Sine, Saw up, Saw down, [00 00 00 00 00 00 00 00 00 00 FE 1F 01 00 00 00 ] * Number of simultaneous effects: 0 Setting master gain to 75% ... OK Uploading effect #0 (Periodic sinusoidal) ... Error:: Function not implemented Uploading effect #1 (Constant) ... Error: Function not implemented Uploading effect #2 (Spring) ... Error: Function not implemented Uploading effect #3 (Damper) ... Error: Function not implemented Uploading effect #4 (Strong rumble, with heavy motor) ... Error: Function not implemented Uploading effect #5 (Weak rumble, with light motor) ... Error: Function not implemented I'm certain this is an upstream bug and for long before the 3.13 version I'm booting, but I'm certain someone here can escalate it upstream faster than I can figure out where the proper place is. The kernel module appears to be attempting to query the stick, but never gets anything back. I glanced through the code where the errors are coming from, but I didn't figure out enough of the flow of logic to even begin to figure out a patch.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
The problem still persists in 3.16.2-200.fc20.i686 I debugged it in kernel 3.13.0. Major findings: - in hid-core.c the function usbhid_parse() is called after the joystick is attached - usbhid_parse() calls function hid_set_idle(), and this one fails while sending an URB (details see below). Reason: the joystick returns -EPIPE. - Same thing can be seen, if Wireshark is used to look at the traffic - According to the documentation, EPIPE means "Endpoint stalled". It furthermore says: "For non-control endpoints, reset this status with usb_clear_halt()." Unfortunately the return value is not checked in the kernel module. I added this check, and tried to do a "usb_clear_halt" on error. However, I cannot quiet understand how things work in the code, and all my trials ended in crashing the kernel. --- hid-core.c:usbhid_parse:1006, ret=2 hid-core.c:hid_set_idle:669 message.c:usb_control_msg:132 message.c:usb_internal_control_msg:81 usb_start_wait_urb: 44 submits URB and waits for response with a timeout not: ret = usb_submit_urb() -> ret is zero *actual_length = 1 ctx: struct api_context { .done:struct completion, .status:int } completion: struct { done: uint, wait: wait_queue_head_t } expire = msec_to_jiffies(5000) = 1250 not: ret = ctx.status or -ETIMEDOUT, since dev_dbg does not appear ret = ctx.status -> so the -32 is ctx.status. This is "broken pipe", as seen in the Wireshark trace
Just found out, that it indeed is an upstream bug. Works in 2.6.38-12.
2.6.38? That is a ways back. When I was doing some research on this, I saw the USB HID kernel code was refactored. I'm guessing that's what broke it. Unfortunately, I couldn't even get as far as you in trying to debug the cause of the problem. Does this section of the kernel have a maintainer here or upstream?
I can narrow it down a bit more: In 3.0.0-12 the problem was not there either. So it came somwhere after that...
Created attachment 980882 [details] Patch for Microsoft Sidewinder Force Feedback 2 Proposed patch to get the Microsoft Sidewinder Force Feedback 2 working. Three bugs are addressed: 1) The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init. However, this is called inside a block where driver_input_lock is locked, so the results of these initial commands are discarded. This one is the "killer", without this nothing else works. 2) The usbhid driver ignores an endpoint stall when sending control commands, causing the first few commands of the hid-pidff.c initialisation to get lost. 3) The FF2 driver does not set the effect ID when uploading an effect. The result is that the initial upload works but subsequent uploads to modify effect parameters are all directed at the last-created effect. Patch created against kernel 3.13.0 .
I have tried the patch from comment #7. It compiles and runs great against 3.17.7-300.fc21. fftest uploads and runs the 5 test effects as expected. Great work. Any chance this can be added against an upcoming F21 kernel or will it need pushed upstream first?
(In reply to Aaron Kling from comment #8) > I have tried the patch from comment #7. It compiles and runs great against > 3.17.7-300.fc21. fftest uploads and runs the 5 test effects as expected. > Great work. > > Any chance this can be added against an upcoming F21 kernel or will it need > pushed upstream first? It needs to be rebased against 3.19 and at least sent upstream for review before we'll grab it. Particularly since it is modifying hid-core. If anyone wants to do that, we'd appreciate it as we don't have hardware to test this with.
Josh, the patch has already been submitted upstream: https://patchwork.kernel.org/patch/5653831/ Alan made some feedback that I agree with, and by looking at it, I have a few more comments. Jim, when your patch gets accepted by Jiri, please mark a comment here and I am pretty sure Josh will be glad to pick it for the Fedora kernel.
Oh excellent! Thanks for the info. I'll keep an eye on this bug.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.