Bug 1092182 - Force Feedback problem with Microsoft FFB2 [NEEDINFO]
Summary: Force Feedback problem with Microsoft FFB2
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-28 22:59 UTC by Aaron Kling
Modified: 2015-04-28 18:24 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-04-28 18:24:58 UTC
kernel-team: needinfo?


Attachments (Terms of Use)
Patch for Microsoft Sidewinder Force Feedback 2 (2.55 KB, patch)
2015-01-16 17:14 UTC, Jim Keir
no flags Details | Diff

Description Aaron Kling 2014-04-28 22:59:51 UTC
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.

Comment 1 Justin M. Forbes 2014-05-21 19:40:43 UTC
*********** 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.

Comment 2 Justin M. Forbes 2014-06-23 14:49:25 UTC
*********** 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.

Comment 3 Martin B 2014-09-16 17:15:48 UTC
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

Comment 4 Martin B 2014-09-16 17:33:17 UTC
Just found out, that it indeed is an upstream bug. Works in 2.6.38-12.

Comment 5 Aaron Kling 2014-09-16 17:42:36 UTC
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?

Comment 6 Martin B 2014-09-16 18:47:21 UTC
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...

Comment 7 Jim Keir 2015-01-16 17:14:40 UTC
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 .

Comment 8 Aaron Kling 2015-01-20 00:52:56 UTC
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?

Comment 9 Josh Boyer 2015-01-20 13:12:59 UTC
(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.

Comment 10 Benjamin Tissoires 2015-01-20 13:57:01 UTC
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.

Comment 11 Josh Boyer 2015-01-20 14:02:19 UTC
Oh excellent!  Thanks for the info.  I'll keep an eye on this bug.

Comment 12 Fedora Kernel Team 2015-02-24 16:24:10 UTC
*********** 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.

Comment 13 Fedora Kernel Team 2015-04-28 18:24:58 UTC
*********** 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.


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