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’… 
Exactly 
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.
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
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.