FFB Wheel

[sonik-br]

Hi!

This will adapt an old gameport sidewinder wheel to work in windows?

[cyberluke]

In wiki there is mentioned it is work in progress and not completed yet. What branch is it, so I someone can continue on it, please?

[cyberluke]

I want to adapt it to Interact FX RacingWheel (gameport + midi, force feedback) wheel. (2 axis, 4 buttons) - good for Trackmania or Revolt.

[tloimu]

Unfortunately, I belive the guy who started the Wheel support has abandoned it. Haven't seen him in years. And I don't have the wheel so I cannot test it, thus cannot advance this part myself.

[ej113]

I wanted to record the current status of the wheel and what works and doesn't. I'm using a build based on the current code in the repo which allows switching between wheel and joystick. There was a previous patched wheel-only hex that may work better.

What works:

• The adapter is able to connect to the wheel
• The adapter provides valid descriptors to windows so that it is recognised as a USB device (I believe the descriptors are identical to the joystick at present)
• The wheel axes and buttons are all reported
• The force feedback can be activated.
• The USB serial port can be used to debug and to trigger FFB effects, using the MIDI message examples in the Wiki and DescentBB thread.

What doesn't work:

• The adapter circuit may need modification to avoid damage. See #49.
• The axes mappings may not be ideal for maximum compatibility with games. I don't think they match the USB wheel.
• The force feedback toggle is reported as a button state. This means that software will see it as a button being continuously pressed, which messes with e.g. button assignments in games.
• The PoV hat switch reports random directions which are not affected by axes movements or button. Occasionally this changes or toggles off, which makes me suspect an overflowed pointer. This also messes with button assignments.
• When using e.g. the JayBee-git fork which modifies joystick descriptors, but not the wheel descriptors, I get an error in Windows Device Manager: This device cannot start. (Code 10) Extra end collection found or end collection not found. I think there is a bug that assumes the wheel USB descriptors are the same length as the joystick ones.
• Adapter seems to connect to wheel too fast to allow it to complete self-calibration, which means wheel ends up off-centre.
• Due either to held buttons or incomplete force feedback implementation causing freezing, I haven't been able to get axes/buttons assigned and test it in a game.

Current mappings:

• X axis = wheel
• Y axis = gas
• Throttle = brake
• Buttons 1,2,3 = A, B,C
• Button 4 = Right shifter
• Buttons 5,6,7 = X,Y,Z
• Button 8 = Left shifter
• Button 9 = FORCE toggle (off when force is on)

[edit swapped X,Y]

[LeZerb]

On https://www.descentbb.net/viewtopic.php?t=19061 I found the USB descriptor of a FFB USB wheel. Maybe this is helpful as a reference.

I recently dusted off my adapter and tried to use my wheel in Forza Horizon 3 but was not able to get that to work without remapping the device as a XBOX360 controller. And in that configuration it was still mostly unusable since the game seems to apply a large deadzone which is not configurable. I suspect that this might be different with a descriptor that identifies the device as an "Automobile Simulation Device" but maybe the game is just very picky when it comes to supported gamepads and wheels.

https://github.com/LeZerb/adapt-ffb-joy/blob/63a651001adeaf055b96de9e99970a88b2634575/SidewinderWheel.pdf

[ej113]

Maybe it is not needed to declare as an "Automobile Simulation Device". The USB wheel only declares itself as: Usage Page (Generic Desktop) 05 01 Usage (Joystick) 09 04

And there is no Simulation Controls page. I wonder what modern racing wheels include in their descriptors. Perhaps putting this in does help some games to automatically map controls.

[LeZerb]

Would you or @tloimu be interested in my wheel. Since I don't think I'll be using it I could send it to you if you are somewhere in the european union (otherwise postage might be a bit much). I don't really want to just throw it in the trash.

[ej113]

Thanks but no - I don't need another one, they're pretty bulky to store!

[sonik-br]

Maybe it is not needed to declare as an "Automobile Simulation Device". The USB wheel only declares itself as: Usage Page (Generic Desktop) 05 01 Usage (Joystick) 09 04

And there is no Simulation Controls page. I wonder what modern racing wheels include in their descriptors. Perhaps putting this in does help some games to automatically map controls.

Modern racing games on windows uses xinput. Xinput have a device type id for gamepad, racing wheel, and so on... The game might apply a deadzone when using a gamepad.

[ej113]

So I looked into this: XInput is actually already regarded by Microsoft as a legacy API and has been replaced by GameInput which also provides support for generic HID/DirectInput devices - perhaps they gave up trying to make everyone use Xbox controllers for PC games. Xinput, using the XUSB drivers, was a closed shop that only works with Microsoft partner devices, although most of the protocol has been reverse engineered, at least for gamepads. I couldn't find the equivalent for Xbox Force Feedback wheels. The security handshake with the XBox console has also not been (openly) broken. Some barely ported Xbox games will only support Xbox controllers or facsimiles on PC using Xinput, but most games & sims with good native PC support will work with DirectInput devices and if not, software like x360ce are available.

It would certainly be ironic to adapt a legacy proprietary closed Microsoft protocol to work with a newer legacy proprietary closed Microsoft protocol...

There are also disadvantages to representing as an XInput device - if it works at all with games that support DirectInput the throttle and brake axes will be combined. Some commercial wheels even have a physical switch to change between Xbox and DirectInput mode because of the incompatibilities and limitations of using XInput on PC.

I also found a fork by @rei0348 that modifies the descriptors to represent the Wheel as Simulation Controls with Accelerator, Brake and Steering mapped according to the HID usage tables. They've also added a fix to allow the Wheel and Joystick to have different descriptors without error. I've tested this code and it appears in USB Game Controller window like this:

(Ignore the title - I haven't got around to refreshing the device name in Windows)

Not sure if this will be a compatibility improvement or not compared to the USB Sidewinder FF wheel descriptors - maybe it will improve mapping with sim titles.

In Need for Speed 3 the axes appear mapped as X, Y and Z. Since the hat is removed and the PID descriptors are commented out it works fine in the game. Just needed to make sure the Force button was toggled to on when assigning buttons and axes - the Force toggle wouldn't ideally get reported as a button.

[ej113]

As a further reference point OpenFFBoard includes all 8 possible control axes in the descriptors which are generic HID. There is a list of compatible games.

Also very useful in this issue is a table of what force effects some different racing games use. This can help to prioritise the force feedback implementation. I knew I'd seen this somewhere but search turned up nothing - was lucky to stumble on it again! From this and what I've seen elsewhere many racing sims use just a constant force updated very fast based on in game physics. Then a damping effect is added to help with control stability. It remains to be seen whether the atmega and MIDI comms can handle the update rates that are required (Min ~60Hz). I think some wheels are using drivers to increase the force streaming rate, then upsampling the force signal within the device to improve the feel. Nevertheless there are reports of the USB Sidewinder FF wheel working with e.g. Assetto Corsa.

[ej113]

Some progress! I've started a discussion thread on wheel force feedback developments here #54. Firmware available for test.