Simucube 2 on Linux

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.

1 Like

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

2 Likes

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.

Deleted regedits from proton prefix, no change in behaviour. Problem seems to be that everytime I start new game, I need to power cycle base and reconnect via Truedrive or else there is no FFB. So meaning that everytime I start new race, Simucube needs reboot to work.

Has anyone managed to do a firmware update through wine?
I updated to the latest truedrive, and it requires a FW update, but my win10 kvm is no longer recognizing the SC2pro when I pass it through. Other devices pass through fine. I’m hoping a new kvm install will help, but it would be nice to avoid windows entirely. Just nervous about the FW update messing up the device if done through wine.

I tried it once with wine but it didn’t work, probably would be the same with kvm. I believe when the device restarts id gets a new ID on Linux level and higher up apps like wine/kvm cannot find the previous anymore, but this is a guess and probably remediable with some research, dunno.

As for me ATM I use a previous version of TD, but yeah, that is somewhat a shortcoming, I used to have dual boot but don’t have anymore, those TD updates where not so common and the current one works perfect, so I don’t really care that much, but if I get a windows on the gaming machine I use the opportunity to update.

Yes, the device will report with different product ID on USB and thus that might need to be added for Linux. Also it presents as a HID device but without a mouse / gamepad / anything else, just a vendor defined reports are specified in the HID descriptor. I don’t know how Linux handles these regarding permissions and such, but writing and reading should work normally.

I’ve been unsuccessful getting the sc2 to work in a win10 vm. It shows up as USB Input Device and fails to start. My HE sprints and my Fanatec shifter both show up as game controllers when I redirect them. This used to work, I used this vm to update the firmware on the sc2 when I first got it.
It also fails to show up in wine/truedrive after a wine update to staging 9.1. Going back to 8.21 fixed that, but I still can’t update the FW through that since it fails to find the device after it sends the command to restart in firmware update mode. I have to power cycle the sc2 to get it to show up again and tell me that it needs to update firmware.
I guess I’ll have to find an older truedrive to reinstall until I can find a win native machine to update with.

Mika, Thanks so much! I went back and re-read your post and realized what you meant about the product ID. I updated my simucube udev rules file adding another line with 0d5e, and the firmware update worked perfectly through wine.

KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d60”, MODE=“0660”, TAG+=“uaccess”
KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d5e”, MODE=“0660”, TAG+=“uaccess”

1 Like

Same here, on a Simucube sport.

I updated the wikipage to reflect this:
https://granitedevices.com/wiki/Using_Simucube_wheel_base_in_Linux

(I also confirmed that firmware upgrade mode always uses idProduct=0d5e independend of the Simucube model.

1 Like