Running on Linux w/ Wheel: A Guide

A document form of this post can be found here.
The BeamNG.Drive Linux Experience

From Nothing to Heel-N-Toe

Preface
This guide will go over on how to get BeamNG.Drive running on your system and configure your wheel. This guide however will not apply strictly to every Linux distribution and files may need to be moved elsewhere on your system to operate correctly or may not be required at all; it is up to you to have a general understanding of your distribution and might be up to preference how you manage your system.

Assumptions

• Steam is installed
  
  
• Wine is installed
  
  • Steam’s Proton could be used if you wish to avoid installing it for any reason, but it’s use will not be covered in this document
    https://community.chakralinux.org/t/8236
    
• iRacing WheelCheck has been obtained
  
  • https://www.dropbox.com/s/3zxf5yd1bvujyi5/WheelCheck_1_72.zip
    
• Steam Play has been enabled in Steam (to allow running Windows games)
  
  
• Understand the basics of navigating a terminal
  
  
• Able to elevate your privileges to edit and move files
  
  
• Basic familiarity with your distribution’s packaging system to install packages
  

Site Specific

• XUbuntu 20.04, Debian-based Distribution, SystemD init
  
  
• Logitech G920
  

Bugs

• Binding keys have a strange delay until they appear to be bound correctly. Menu operates quickly, but it is as if the input system takes a bit of time to finally recognize. Doing Ctrl+L can help quicken this.
  
  
• A very small deadzone is required for wheel pedals (and maybe other joysticks) for the start of the input, otherwise the game registers a very, very small value after the brake is released which can mess with automatics and TCS.
  
  
• Nitrous systems do not automatically fire when full throttle like they should.
  
  
• Some wheels may need to have their mode changed via a command or a udev rule.
  
  
• You may need to explicitly set your force feedback update rate otherwise you will get increasingly delayed force feedback. You can see when if this is happening by watching kernel messages with something like `dmesg -w`.
  

First Steps: Getting BeamNG.Drive
Warning: If you are moving your library from Windows to Linux or reusing your existing location, do not do this. Steam will likely delete your game files inappropriately upon adding due to it obtaining incorrect files.

Mark BeamNG.Drive for install which will happen unusually briefly. This is because the Steam Linux Runtime for BeamNG.Drive doesn’t actually obtain anything useful so you must go into “Properties” and set your Steam Play compatibility tool to a version of Proton. A recent version of Proton (5.13-1) works fine at the time of writing. After this has been done, Steam will now actually obtain the files.

Quick Test & Keyboard Play
The game should be playable as is with just a keyboard and mouse. Loading maps, vehicles, driving them around and anything you generally want to do with BeamNG.Drive will work at this stage. The only quirks so far is key mapping is incredibly buggy

Wheel Duality
If you use the G920 wheel on Linux you will discover that it is not detected by BeamNG.Drive or at least partially functional. This is due to the wheel by default starting in “Xbox Mode” requiring a USB mode switch to expose all the features to the OS and have kernel drivers wire up the joystick configuration and even provide force feedback. This explains why in Windows the wheel will re-calibrate twice during boot or whenever G Hub preforms an update; the wheel is changing modes. You may need to do this for other wheels and you will need to research what usb_modeswitch definition they used to correct this.

Research online shows that it should work but in my case my wheel does not switch it’s mode upon plug in even though it appears as though it should. And trying to research a proper solution to the issue yields nothing, so we will create a file with root/sudo privileges under /etc/usb_modeswitch.d/ and wire it together with a udev rule under /etc/udev/rules.d/. Again, consult your distribution documentation for proper locations for these files if you’re not on a Debian/SystemD system.

Create a file under /etc/usb_modeswitch.d/ named 046d:c261 to store your modeswitch definition with the following contents.

# Logitech G920 Racing Wheel
DefaultVendor=046d
DefaultProduct=c261
MessageEndpoint=01
ResponseEndpoint=01
TargetClass=0x03
MessageContent="0f00010142"

The comment up-top is for our reference. It’s suggested to do this for any configuration changes you do for yourself.

Create another file under /etc/udev/rules.d/ named with a non-conflicting rule like 41-g920-wheel.rules with the following contents, changing PATH/TO/DEFINITION to the location of your definition. The absolute path for usb_modeswitch is required otherwise it’ll attempt to run a service of the same name, and you may need to use the `which` command to locate it.

ATTR{idVendor}=="046d", ATTR{idProduct}=="c261", RUN+="/usr/sbin/usb_modeswitch -c 'PATH/TO/DEFINITION'"

You may add a comment using the hashtag (#) symbol above the line for reference if your file name wasn’t appropriate.

Finally, run `service udev reload` to parse your changes, unplug and replug your wheel, and it should be ready to be used in BeamNG.Drive. Use `udevadm monitor` to watch for issues parsing your udev rule and `lsusb -v -d 046d:c261` to confirm that the wheel no longer has 255 for it’s class, subclass, and protocol. You can also do `ls /dev/input/by-id` and see if your wheel appears.

Laggy Wheels and Calibration
After configuring your wheel in BeamNG.Drive, you might discover that the force feedback will become more and more delayed, especially with aggressive driving. This is the result of the force feedback queue filling up and you will need to set your update rate to one that agrees with your wheel. You can use `dmesg -w` to watch when it happens.

Ideally you would also want to compensate for your wheel’s motor imperfections so forces upon it feel closer to real life, so we will use WheelCheck to generate the `.csv` file we need to give to BeamNG.Drive.

Using Wine, run WheelCheck, use “Wheel with Force (PID)” as the spring force, and adjust the “Sleep” time until you stop seeing kernel warnings about the force feedback queue overflowing. Unusually in WheelCheck, the “0” value isn’t the wheel center, instead it is a few rotations off which will result in the wheel colliding at the extents when we run “Step Log 2.” The best that can be done is setting the “Offset X” all the way to the right, then running “Step Log 2” with Max Count adjusted to preference and wheel. 50-100 tends to be the general consensus, but it’s based how many different forces your wheel can produce.

Once the step log is finished, a `.csv` file will be in your Document folder for your user and you will now rename this as `wheel.csv`. This file will be placed at
`~/.steam/steam/steamapps/compatdata/284160/pfx/drive_c/users/steamuser/My Documents/BeamNG.Drive/settings/inputmaps/`
Then finally enable the Response Correction Curve in BeamNG.Drive. If all went well, you should see your graph appear.

Finally, add a small deadzone to the brake binding at the start of it so the game doesn’t see a small brake input and cause automatics and TCS unable to work correctly.