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
Apologies for reviving a year old thread.
I just got a Simucube 2 Sport. Amazing piece of hardware!
The logs show udev rules being applied, the device is correctly identified, and it is connected. I installed Simucube Tuner instead, which is also supported, right? The application opens, but the wheel is not connecting.
Any ideas where to look?
I don’t think we have tested Tuner at all on Linux.
Please check that the wheel base support is enabled in Tuner settings.
Thanks for the suggestion! I tried with True Drive first, but it complains about the firmware being too recent and wants to downgrade it.
Tuner doesn’t see the wheel at all, even after enabling it. iRacing sees the base and I can calibrate, with FFB working properly but I can’t see the steering wheel because it’s wireless (Artura Pro).
It works. Vanilla Wine implementation doesn’t have HIDRAW enabled by default, but Proton-Wine does. I changed the Wine prefix to an existing Proton prefix and everything works, flawlessly! 
I honestly did not put a lot of energy into it, mainly because I prefer the former True Drive app, it’s more simple 
But I will test the tunner with a wine from a prefix and see, maybe I should ignore the new interface and focus that the new firmware may be fixing stuff.
Then I could also update that guide.
thanks for the feedback!
Simucube Tuner works really well on Wine. The same requirements that are valid for True Drive apply here as well, i.e. enable hidraw in the prefix, add udev rules for SC2 + “firmware” device, etc. All important features work, incl. firmware update and automatic profile switching. Obviously you need to use/run one wineprefix for all your games, so ST would see the game binary running. This is easily achievable with Wine/Wine Staging and Steam (Win) installed on the prefix.
The only feature that currently works on Proton, but not on standard Wine, is Paddock integration. The CEF component used there requires hardware acceleration which needs shared gpu res implementation (available only on Proton for now). Maybe if GD provides some way (via command line option, etc.) to run this with software acceleration, then this issue will be solved for Wine prefixes as well.
I think you can try to put a software version of the opengl dll file to the Tuner installation directory. I’m not sure if it takes effect, though. There are compilation options in Qt that affect it also, and my memories are from the Qt5 days and it might have changed in Qt6.8
What do you mean one wine prefix for all games? Proton does create a dedicated prefix for all games.
In my case I can also not use the default wine(nor staging), just created a new prefix, added the 2 registry entries, installed Tuner.exe, doesnt work, installed True Drive, works fine.
The Tuner interface opens, but it does not detect the base.
One (single) prefix as one unified Windows installation.
Proton creates separated prefix (Win installation) per game - each with their own wineserver, memory space, services, etc. - so they “see” only the processes that run in their own prefix. I think there is utility for Proton (Steam Play) that allows customizing all aspects of this incl. custom prefix path. In theory pointing out all the games to a unified prefix and then running them with the same Proton tool, should do the trick. There is also STEAM_COMPAT_DATA_PATH env var, which seems to do the same. GE’s umu-launcher also looks to be capable of this.
I have installed Steam (Win), all my games and utils like Simucube Tuner, SimHub, CrewChief, TrackIR5 etc. in a single wineprefix, just like a normal Windows installation. This way they all run in the same Win environment, can use shared memory between processes, can interact via various IPC techniques, can “see” other running processes (games) and eventually autoswitch profiles like Simucube Tuner and SimHub, etc. I just start the needed utils first, then the games, and everything works as expected.
I’m using Wine Staging + some patches backported from Proton, some of which are available in the wine-tkg repository. Anyway, none of these should be needed for ST to function properly. I have “Enable SDL” = 0 and “DisableInput” = 1. There is a new key “EnableHidraw” (type REG_MULTI_SZ), which is recommended to use in place of the old keys, though. It needs pairs of vid:pid listed for devices that should be added only through hidraw. For example:
16D0:0D61
16D0:0D5E
I don’t remember what happened when I first installed ST, but current version requires FW update. Maybe check if there is a FW update available in the Firmware update tab.
I’ll check with standard Wine and report back.
@Mika, thanks I’ll try that. I think there are also other techniques to force CPU rendering in CEF, that involve hacking in the Wine launcher code to add the needed cmd line options for the CEF processes. Proton devs use such methods for some CEF apps. Although such hacks aren’t accepted in upstream Wine.
Can you guys try to compile the CEF app with CPU rendering by default. It works very well and it is not demanding at all. I have tried this in LMU, which is also a CEF app. The menus and everything worked much smoother this way.
It is unlikely we would do these types of options to our CI pipeline for the Linux users only.
No problem !
Support for GPU rendering in CEF is already in Proton, so it’s just matter of time until they make it ready for upstream Wine.
My point is that CPU rendering might be a better option for your use case in Windows as well. It’s more compatible, fast enough for non-3D stuff (which your app seems to be), smooth for non-3D stuff, etc. Anyway, I don’t know how QT6 integrates with CEF, so it might be quite difficult to implement this.
Installed Simucube Tuner 2.6.1 in a new wineprefix with Wine 10.11 (mainline). After setting “Enable SDL” = 0 and “DisableInput” = 1 in the registry, it recognized the wheel and worked out of the box, except for the Paddock feature.
I already have firmware 2.6 installed, so this might be the reason why SC2 shows up immediately in my case. As I posted earlier, maybe it needs a Tuner firmware flashed, before showing the base in the UI.