Simucube 2 on Linux

This is a ‘Extraction’ from this topic: Driving Simulator for Vehicle Research which has become to big and easy to get lost, so I extracted the most vital info to make simucube 2 work on Linux, based on my own experience as I’m using the Simucube2 Sport for some time now on Linux, the credits for me being able to write this guide goes to all that commented on the above thread.

The latest released(upcomming) driver: 2022.10 ( added some missing descriptors needed by Linux, so this guide only works with upcomming latest firmware >= 2022.10

Install Wine, preferably wine >= 7.17

To isolate this truedrive setup we will use a WINEPREFIX, you can use whatever wineprefix name you want.

mkdir ~/simucube
WINEPREFIX="~/simucube" wine regedit

In the windows registry opened with the command above:
Create “Enable SDL” in [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus], which must be added with right click->New->DWORD value, and set to “0”

Create “DisableInput” in [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus], which must be added with right click->New->DWORD value, and set to “1”

Install truedrive:
WINEPREFIX="~/simucube" wine Simucube_2_True_Drive_2022.10.exe

Create the bellow file, (make sure the double quotes get pasted correctly):
The hidraw user access for SC in Linux can be enabled by placing a file “72-simucube.rules” in “/etc/udev/rules.d/” with the following content:

Simucube 1; USB

KERNEL=="hidraw*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d5a", MODE="0660",                

Simucube 2 Sport; USB

KERNEL=="hidraw*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d61", MODE="0660",    

Simucube 2 Pro; USB

KERNEL=="hidraw*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d60", MODE="0660", 

Simucube 2 Ultimate; USB

KERNEL=="hidraw*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d5f", MODE="0660", 

Power one the simucube base, open true drive, see it if connects.

Install steam, go to steam settings and set it to use proton.
Game should install and wheel work.

For Raceroom you want to use Proton version 6 (you can change proton version per game)

Usefull other apps:


We’ve set up a wiki page to document this, as it gets easily lost on the forum. PM me if you want to write this there.


Wasn’t Mika tinkering with a linux version of Truedrive in the early days?

I did, at one point, get a native Linux build of the Simucube 1 Configuration Tool to work. But it was in a virtual machine. And no FFB things were tested.

What is going to be possible in the upcoming release with proton/wine and such things, will already be much better and no need to get a native build to work.

But is it safe to do e.g. a FW Update using wine and hidraw?

I have not tried yet as I have a multiboot. It’s quite an expensive hardware to become ‘adventurous’… :slight_smile:

Exactly :wink:

Especially, since I have a SC1 and there are no replacement parts anymore.

I’m preparing a patch to systemd to remove the deadzone on the devices. One question to the Simucube 2 users: do these devices also exhibit 8 analogue axes like the Simucube 1, or is it different?
How many axes should be addressed? Only the steering axis? (which is axis 0)
To find out, run e.g.:

evdev-joystick --showcal /dev/input/by-id/usb-Granite_Devices_SimuCUBE_0123456789-event-joystick

That’ll give something like this:

Supported Absolute axes:
  Absolute axis 0x00 (0) (X Axis) (value: 0, min: 0, max: 65535, flatness: 0 (=0.00%), fuzz: 0)
  Absolute axis 0x01 (1) (Y Axis) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x02 (2) (Z Axis) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x03 (3) (X Rate Axis) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x04 (4) (Y Rate Axis) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x05 (5) (Z Rate Axis) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x06 (6) (Throttle) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)
  Absolute axis 0x07 (7) (Rudder) (value: 0, min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)

I think for the Simucube 1 it’ll make sense to set the deadzone to 0 for all axes, since it supports analogue input via the X11 upper/lower connectors.

How is are the wireless wheels handled? For the new version, I think there are analogue inputs as well, are these additional axes in the Simucube or are they added as an additional device?

The interface is exactly the same in both Simucube devices.

btw, that patch for wine was merged, so for the next Proton Experimental, it should be included.
And of course Proton-7.0-6 or whatever the next stable Proton version will be.

Furthermore, for systemd 253 or later, setting the deadzones should not be required anymore. They merged my patch to hwdb for that:

1 Like

I have added the definitions in my local systemd-hwdb and it indeed removed a small deadzone I had, thanks!

Cannot edit the main post, but if you cannot open the online profile on the simucube padock software, you need to import the .exe from the wineprefix you used on the above tuto into Steam and set the created steam simucube entrie to use proton (in compatibility mode)

The Proton/Wine change for Simucube is now also part of the popular Proton GE build, so if you’re using that, it should work, too.

Worked a charm. Couldn’t get it to work when I found this post, but there was a minor detail about it working for the upcoming software release :slight_smile:

Installed the new software today and it worked. Minor correction to the instruction can be done regarding the path, for me the ‘WINEPREFIX="~/simucube" wine regedit’ command didn’t work well. I know the ~ is a short for your home directory, and it works when I do a cd + home button in terminal, but it did not want to take when I used this with the WINEPREFIX command.

Most likely that’s due to the quotes. It might depend a bit on the shell that is used, though.
Typically, the ~ is expanded by the shell to the path to your home directory. e.g. if you do

ls ~/simucube

what is actually executed is

ls /home/user/simucube

Therefore, trying

ls "~/simucube"

won’t work, because the ~ is not expanded and ls can’t find something with that path name.

1 Like

While this seemed to work on the first few meters, I have later noticed how I don’t really have any ffb in ACC. Any pointers on what to start looking at?
The input works, and I have the same truedrive profile as I use in windows, with the same settings ingame. However I have no ffb beside a bit of center locking. That is there is a littlebit of force holding the wheel center, but nothing when I am in a turn. It feels like I have 100% static force reduction, and no lateral forces on the weel at all.

Sounds like if the ‘high torque’ is disabled.

Got fully working FFB and Truedrive with this guide, using Lutris + Wine to run Paddock.
However, when running game (Assetto Corsa) from Steam+ proton, I got some problems. Game recognizes Simucube, but there is no FFB.
I have made Enable SDL and DisableInput regedits to wineprefix running Paddock, and proton prefix running AC. Sometimes with pure luck it seems to work, but I think there is somekind of “connection” problem between Wine and Proton.
Mostly playing RBR via Lutris and it works like a charm, although they run in different Wine prefixes.

Does anybody have any ideas what might be the problem?

You don’t need to do anything on the proton prefix or steam wise, only the wineprefix that runs the simucube sofware, as soon as it makes the few beeps signalizing high torque is activated you are done, you can close true drive and even reboot the machine as it will keep the high torque activated.

Maybe by adding the regedits to more prefixes you created some kind of conflict.