Linux steering wheels FFB support

Ranks

Ranks are based on user testing and results may vary due to differences in the hardware.

Platinum

Works fully with the recommended driver with extensive testing. Most common FFB effects implemented.

Gold

Works fully but it's less tested and there might be some minor issues. Most common FFB effects implemented.

Silver

Works almost fully. Some FFB effects might be missing or some other significant issues which might be important in some cases. Workarounds might be available.

Bronze

Major bugs or missing FFB effects which limit its use. It might be enough in some cases but it's far from fully working.

Broken

The device might be recognized as a gamepad/joystick but there's no FFB.

(empty)

Device not tested at all. May be working, may be not. Contributions welcome!

Table of compatibility

Read also related sections for each driver below for more information.

hid-pidff

The kernel module hid-pidff implements the HID PID specification. HID PID is a standard for USB devices which includes FFB. Although this standard is several years old, most older and low end wheels don't implement it, but most high and some middle end wheels do.

With Linux 6.15, the generic hid-pidff driver was upgraded and made more compatible with wide range of devices out of the box. Some devices still need some fixes like fixed direction for Moza deivces (caused by a bug in SDL which was fixed), permissive device dontrol field search for VRS. More importantly, Moza, Camus and others define more than 80 buttons which is a current Linux limitation for joysticks and gamepads.

Linux 6.15 introduces hid-universal-pidff, an extension to the generic PID driver, which extends usable button range, sets better default fuzz/flat values and can be made to fix device descriptors if needed. Additionally, it enables us to provide an initial set of newly-introduced pidff quirks.

[!NOTE] hid-universal-pidff and patches to hid-pidff were backported to 6.12.24, 6.13.12 and 6.14.3. Some of the patches were backported to even earlier kernels but maintainers decided not to work on backporting all of them thus 6.12 is the current cut-off point for support.

Duration issue

[!NOTE] Fixed in Linux 6.15

The driver doesn't play any FFB effect out of the box due to a flaw in its API.

Although undocumented, Linux drivers and applications (including Wine) have always used value 0x0 for an infinite effect length, but the hid-pidff driver uses value 0xFFFF instead. When an effect with length 0x0 is uploaded, it plays no effect. The HID PID specification defines an infinite length effect with value 0xFFFF but this specification is for the hardware and isn't tied to Linux in any way.

To work around the issue without custom drivers you could use ffbwrap tool. For example, launch games with command:

ffbwrap --duration-fix /dev/input/by-id/usb-Your-Wheel-event-joystick %command%

a7 descriptor issue

[!NOTE] Fixed in Linux 6.15

Descriptor 0xa7 (effect delay) is not required for Windows HID PID implementation. Some manufacturers (including Simucube at first, later Simagic and Cammus) didn't implement that parameter in their firmware. But in Linux HID PID implementation 0xa7 descriptor is mandatory, and device without it can't be initialized with hid-pidff driver. Simucube fixed it in latest firmware (1.0.49).

Some devices will require a patched hid-pidff driver which removes 0xa7 descriptor requirement and enables FFB.

hid-logitech-hidpp

This module implements HID++, Logitech's own specification for FFB. It's used in wheel models compatible with XBox. This models do almost everything in hardware, while models using hid-logitech need assistance from the driver.

Queue full errors

In some games, when using this driver the FFB can lag behind so much that it's unbearable.

This driver sends commands to the wheel at the same rate they're sent by the game. When the game is sending FFB commands at a very fast rate the command queue fills and a warning message appears in dmesg about the full queue. As a consequence the FFB starts lagging behind and looses some FFB commands.

In some games, the rate at which the FFB commands are sent is tied to the frame rate, thus it may work well at lower frame rates but fill the queue at higher frame rates.

Some games allow to configure the rate at which FFB commands are sent. Lowering that value can help and even fix the issue.

ffbwrap can be used to work around it when the application can't be configured to send commands at a lower rate. Needs testing.

Device is infinitely rebooting

1. All of Asetek products
2. Simagic GT Neo

Some devices from the list have internal function/bug, which will reboot the device internals if it's not polled. Device reconnection won't happen if anything opens the device (game, tool, etc), so it only affects idle state. Windows polls the devices all the time by default, Linux does this more efficiently and starts polling only when device file is opened by some application. You can force HID_QUIRK_ALWAYS_POLL for these devices. You will need to change kernel cmdline and regenerate initramfs.

Here is instructions for how to do it in grub:

1. Open your /etc/default/grub
2. Find line GRUB_CMDLINE_LINUX_DEFAULT
3. In the end of this string, add usbhid.quirks=0xVID:0xPID:0x0400, where 0xVID is your device VID, and 0xPID is your device PID
4. Save file, regenerate grub config

grub-mkconfig -o /boot/grub/grub.cfg

5. Regenerate initramfs

• Debian

  sudo update-initramfs -u
  

• Arch

  sudo mkinitcpio -P
  

For distros which using rpm-ostree (Fedora), this line should be enough:

sudo rpm-ostree kargs --append=usbhid.quirks=0xVID:0xPID:0x0400

In the end, consider sending VID PID of the device somewhere we can see (issues), so we can send patches to the kernel, to set this quirk by default on these devices!

SDL

SDL tries to heuristically guess which devices are gamepads and ignores everything that doesn't look like one. This means wheels and pedals might be ignored by SDL. This has been partially fixed by adding a whitelist of wheels. This list has to be updated continuously with new models being tested. These devices will be recognized as joysticks (not gamepads) in Proton.

Recent updates to SDL created SDL Hint variable to dynamically extend wheel devices list. You need to set SDL_JOYSTICK_WHEEL_DEVICES variable like so: SDL_JOYSTICK_WHEEL_DEVICES=0x<VID>/0x<PID>,0x<VID2>/0x<PID2>.

Wine/Proton caveats

Joystick detection

Even if the device is ranked well, there may be some small issues regarding wheel detection. This comes from different approaches from different manufactures: some devices has same buttons as XInput gamepads (A, B, X, Y), and can be mistakenly detected as such.

At first you should check if device is detected by your system as joystick. If it does not shows up as joystick in something like jstest or udevadm info or System settings, you should create new hwdb entry for your specific device.

Check out https://github.com/JacKeTUs/simracing-hwdb, community-driven collection of hwdb entries for the various simracing devices.

If your device is not on the repository above, you can create hwdb entry yourself (and consider contributing to the collection)

Create file /etc/udev/hwdb.d/99-simracing.hwdb with this content (replace VID PID by upper case VID and PID of your device):

id-input:modalias:input:*vVIDpPID*
 ID_INPUT_ACCELEROMETER=0
 ID_INPUT_JOYSTICK=1

This will set JOYSTICK type to the device, and explicitly set ACCELEROMETER to 0 (if you have, say, pedals with 3 axis).

For example, for VRS DFP file will look like this:

# VRS DFP
id-input:modalias:input:*v0483pA355*
 ID_INPUT_ACCELEROMETER=0
 ID_INPUT_JOYSTICK=1

Then reload hwdb database and reload all udev rules like so:

sudo systemd-hwdb update
sudo udevadm trigger

Also, for devices not present in SDL wheels whitelist, Steam uses sandboxed SDL1.2 to detect devices. It has one small rule to detect all kinds of joysticks, function EV_IsJoystick(). And basically, for the device to be classed as a joystick, it must have either X and Y axes or a X and Y hat, and must have a trigger, A button, or 1 button. On some devices Y axis not exists (Logitech G Pro), and therefore, for SDL, that device is not a joystick and no need to forward it to the game. Native apps will work perfectly, Wine apps too. With Proton 10 all devices classified as Wheels in SDL will be detected in Proton as DInput devices.

Alternatively, Boxflat has "Detection fix" functionality for Moza devices.

Link to the Proton issue

Steam settings for ~all devices and ~all games

1. Turn Steam Input off in game settings

2. Use recent Proton version for non-native games. 7 version known for having issues with HID devices detection. 10 version known for fixing various detection bugs, for devices without axis (shifters, buttonboxes) and such.

3. Use recent SDL library version, if you're using native Steam installation.

4. Check if your system detects the device as joystick. If not, create corresponding hwdb entry (see Joystick detection). When your system detects your device as joystick, you can try it in games.

5. If game still does not detect your device, try setting SDL Hint environment variable in game launch command like so:

   SDL_JOYSTICK_WHEEL_DEVICES=0x<VID>/0x<PID> %command%
   

   This is only relevant for devices which are, for various reasons, not in a SDL whitelist (yet), or for older Steam runtime versions which does not have updated SDL library with updated lists.

6. If Proton still can't see your device, you can try and fallback to hidraw protocol by setting PROTON_ENABLE_HIDRAW environment variable. This should be used as last resort, as some versions of Proton are not correctly passing FFB to the hidraw device.

   PROTON_ENABLE_HIDRAW=0x<VID>/0x<PID> %command%
   

7. If none of that worked, create an issue, where members of the community will try to help you with your specific game/device combination.

Links

• Logitech FFb Protocol v1.6.
• hid-logitech-hidpp kernel module.
• hid-pidff kernel module
• OpenFFBoard.

DISCLAIMER

[!CAUTION] THE SOFTWARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Footnotes

1. You need to enable "high torque mode" after device is turned on/plugged in. More info here: asetek_wheelbase_cli ↩ ↩² ↩³ ↩⁴

2. Full native support since Linux 6.15. Plug and play ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹

3. See reconnecting issue ↩ ↩² ↩³ ↩⁴

4. See section on joystick detection. ↩ ↩² ↩³ ↩⁴

5. Custom module hid-fanatecff ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

6. Default driver lacks most effects. Use patched driver. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

7. Full USB command queue errors. Using ffbwrap can help in some situations. ↩ ↩²

8. Not supported by default driver. Use patched driver. ↩

9. Not supported by default driver. Use patched driver. ↩

10. Slightly changed PID protocol, without PID descriptor. Use simagic-ff driver. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

11. Read here about how to setup Simucube base. And a Success case. ↩ ↩² ↩³ ↩⁴

12. Custom module hid-tmff2. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

13. Custom module hid-tminit. ↩

14. Some VRS DirectForce Pro units have a "power saving" feature which disables force feedback up until the wheel is moved a little. Doesn't hurt it's normal performance. Happens on Windows as well. ↩