It should work on Linux when we get a next release out 
2 Likes
Since this thread got a lot of new info I tried again to have my Simucube 2 Sport working on Linux, and want to share where I ended and what was done, so hopefully can help someone that will also try, but it’s basically a summary of wat was said above, my goal is to run raceroom with proper forcedeedback.
- Install wine, for some reason wine-7 did not do it, but wine-7.17 did, so I guess a lot of patches have made it in.
- run
wine regeditand add theEnable SDLmentioned above. - Add the udev rule(if you copy from this page pay a lot of attention as some chars sometimes are pasted differently in the terminal) in my case(simucube sport(you can see other models id’s above)):
localhost:/home/slemke # cat /etc/udev/rules.d/72-simucube.rules
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0d61", TAG+="uaccess", MODE="0660"
- Install true drive:
wine truedrive_installer.exe - Install steam, go to steam setting and set it to use proton, install the game (in my case raceroom)
- reboot, why not?
- After reboot, truedrive opens, and connects to the simucube (it’s weak, sometimes it disconnects and cannot connect back, but it’s something).
- raceroom opens, no forcedeedback on the wheel.
that is basically where I stoped for now.
1 Like
Every wineprefix is like a separate Windows install. So, in your case there is the default wineprefix, which is located in /"user folder"/.wine/. This prefix contains everything, which is installed through the “wine” command, when no “WINEPREFIX” environment variable is declared in the current session.
And there are the prefixes, which Proton builds “behind the scenes” for each proton game. So, R3E has its own wineprefix, with its own registry and installed programs, that can interact only within the prefix. This is done for more security and flexibility.
Since TrueDrive is needed only to control SC2, it can be installed in a separate wineprefix, as you have done. I have TD installed in a separate prefix as well. If you want to use a different prefix than the default, just set the WINEPREFIX environment variable, prepending the “wine” command. Something like this:
WINEPREFIX=/home/user/.wine-truedrive wine truedrive_installer.exe
Proton is using the SDL backend for FFB, which goes through the standard Linux HID PID driver. The current SC2 firmware is not compatible with the driver, so no FFB at the moment. Even if you disable the “Enable SDL” registry value of the R3E prefix (which isn’t set yet ), it won’t enable the hidraw backend. This is a difference between Wine and Proton. There are few devices that go through the hidraw backend in Proton and they are enabled directly in code.
Fortunately the next SC2 firmware clears the HID report descriptor issues, so it’ll be recognized by the Linux PID driver. This will bring FFB to all Proton titles.
Don’t forget to set SC2’s deadzone and fuzz in Linux to 0, as @Berniyh mentioned above.
Here is my hwdb file for SC2: 61-simucube.txt (744 Bytes)
Just rename it to 61-simucube.hwdb and place it at /etc/udev/hwdb.d/ as superuser. Then issue the following command as superuser:
systemd-hwdb update
BTW, the above should also be done for the pedals you use. Esp. the fuzz value really messes up the devices linearity.
I still plan to upstream a patch, that will enable the hidraw backend for SC devices in Proton. This would bring some additional benefits, as setting the steering wheel rotation angle (from games that support it), etc. Obviously it would bring independence from the Linux FFB subsystem (PID driver, etc.).
Also the above udev and hwdb rules need to be pushed up to systemd, so that they come automatically to people’s systems with the next systemd update.
Hello, thanks for the explanation on the WINEPREFIX, I assumed it was somekind of ‘profile’ per application, as I made this install specifically to test the simucube ffb on Linux I just used the default .wine and erased it when needed a ‘reset’. But then you mentioned that proton uses a WINEPREFIX per application/game it made me think imediatelly that this was the problem, as I did not do the regedit change on WINEPREFIX used by proton for raceroom, but then you also mentioned that it will not make a difference so I did not even bothered.
So I think I’m also waiting on the next true drive that fixes the simucube HID report descriptor as currently, on raceroom, the tab that contains the forcefeedback setting is grayed out, more or less meaning that the game is not detecting a forcefeedback wheel.
Untill this update comes out, currently, the only way to make forcefeedback work in proton games(like raceroom in my case) is to applly a patch that ‘hardcodes’ the correct HID descriptor into proton? (IIRC I saw a patch somewhere in this thread)
thanks!
One way would be to patch the Linux HID PID driver and then recompile either the whole kernel or at least the usbhid module.
Other way would be to enable the hidraw backend for SC2 in Proton 7 through a patch. Then use either GE’s (GloriousEggroll) or wine-tkg’s github repository to compile a new Proton BleedingEdge runtime.
Both options are not trivial, so maybe your best choice is to wait for the new Fw. There is also a beta test in progress, which was announced here: DirectInput effects
2 Likes
All right, one more baby step given on proton/racerom (beta2 fw)
Now raceroom recognizes the simucube as a forcefeedback device, wine opens truedrive properly and connects to the wheel, next block is when I open a practice session, when I click ‘drive’ to leave the pitlane it freezes, as there is somekind of lock happening between the simucube and wine/proton. No clue for me this time.
Correction: After switching from proton7 to proton6 raceroom now works properly with ffb.
1 Like
Probably the device ids in the game’s wineprefix registry are mismatched due to the changes in the device type and functionality - ie. joystick vs ffb steering wheel, etc. In this case the best solution is usually to delete the game wineprefix (after backing up the game settings). The next time the game is launched, proton will build a new wineprefix, which should work properly.
But if it works on proton 6 and you are happy with the performance, then just use it that way. If you switch back to proton 7, it’ll reset the wineprefix, incl. the registry, due to switching to a higher proton version. So there is a chance it’ll work on proton 7 without needing to delete the prefix manually.
The wineprefix of R3E is located here:
/“the game drive, ie.-> ~/.steam/root”/steamapps/compatdata/211500
The R3E data is located here:
/“the game drive”/steamapps/compatdata/211500/pfx/drive_c/users/steamuser/Documents/My Games/SimBin/RaceRoom Racing Experience/
I tried back and forth sometimes, with the prefix removal, this one seems really not to work with proton >=7 - More as curiosity as performance on proton 6 way better than how it runs on windows.
Maybe it was somehow not implemented on proton7? It seems it was originally fixed here https://github.com/ValveSoftware/Proton/issues/1321#issuecomment-939676389
And a little for the truedrive topic, with the Enable SDL tweak it opens fine (sometimes have to turn the wheel off and one so it gets re-registered in the system), the truedrive app opens, connects but after a while a loses the connection to the wheel (but that is not problematic as if you connect once to the base with truedrive it keeps working for the entire session, even leaving/entering other games).
So dunno if this disconnection is related to wine or some design of true drive app. (for my use case it’s not a problem as I do not make changes on true drive anyway, and firmware upgrades I do on windows)
For me TrueDrive works really well, in both offline and online mode, without device disconnections or instability. You could try to disable the evdev backend, since there is a bug that would crash one of the winedevice.exe processes on a keypress. It has exactly the same symptoms in TrueDrive.
Just add “DisableInput” value (set to 1) to the winebus key in the registry, the same way as “Enable SDL”.
Also make sure you close TrueDrive before playing games, as it’s installed in a different wineprefix and may consume hid input reports, that potentially are needed by game’s wineprefix. Wine takes care of this only for programs running on the same wineprefix/installation. It shouldn’t be much of a problem though.
Updates:
Yeap, the ‘DisableInput’ register key did it for the disconnection problem, truedrive now fully keeps connected to the base.
Probably more wine related as well:
If I click to ‘Go to true drive paddock’ - which is the online part of it, it just flashes white 2 times and then shows no profiles at all, probably need to install something via winetricks for that rendering.
And, found this one: https://github.com/frostworx/steamtinkerlaunch that let’s you run more apps on the wineprefix that is used by steam/proton, for example, in order to run otterhud on raceroom I need to run(fork) dash.exe in that same wineprefix, which can be easily done on the application launcher like bellow:
It probably also works for other apps like simhub and crewchief.
Good stuff!
if we somehow could get those 2 registry changes into wine then installing truedrive on Linux would be more or less like doing it on windows. If such change is not accepted upstream it’s also very simple to make a shell script that does all of that, even the udev rule add.
thanks for all the tips! Looks promising from simucube / Linux, I mean, not promising, a reality, as I’m using it normally, and performance wise, for gaming on Linux is way better, at least in my case (ryzen/amdgpu)
Yeah, seems there is some regression between Wine 7.17 and 7.18. Tried it with my own build of Wine-staging 7.18 + patches, and it crashes in the online paddock part. While with Wine 7.17 (from Arch Linux) it works properly. Will have to update and try with Wine 7.18 from Arch.
The utility above looks handy.
This is one of the disadvantages of using a separate wineprefix per game. For this reason, and for easier development, I have installed Steam for Windows in a single wineprefix. Not all games work with standard Wine/Wine-staging though. But after porting some of the needed patches from proton, it’s OK. And I can use CrewChief, SimHub, JoyToKey, etc. in one install.
I know this evdev bug, since I reported it about ~8 months ago + a patch to fix it. The sdl backend is default, so it mitigates the problem. But after that backend is disabled, the next is hidraw and then evdev, which crashes while parsing a keyboard report descriptor. The Wine devs probably overlooked the issue, since it doesn’t happen in normal prefixes.
However, they won’t accept disabling the sdl backend as this is the most compatible solution. IMO what is needed is to reverse the order of running with hidraw first (evdev disabled) and then sdl for compatibility. It’s not trivial to do, though.
May rise the issue again and discuss with them, if time permits.
I tested TrueDrive in Wine 7.18 and it works as expected incl. the online part. Tried searching for profiles, applying profiles, etc., all seems to work properly. So the crash I’m experiencing is not related to Wine (standard). Probably some of the staging patches or my backported proton patches.
@S.R.Lemke, try Wine (standard) if you are using staging. The problem might be in staging. Also make sure it is not running in some kind of sandbox (flatpak, snap, firejail, etc.), that is denying network access. I have the same behavior with TrueDrive on Windows, when I block outgoing network connections with Windows Firewall.
I also tested R3RE with Proton 7/Experimental, and you are right that there is some problem with it. In my case it is crashing when getting into a car. The issue also exists on my custom staging build, so it’s most likely the SDL backend, since hidraw works perfectly. I’ll look into that.
Regarding the Proton 7/Experimental R3 crash:
With proton6, when I click ‘drive’ on R3, after some 1/2 seconds I see I quick micro-freeze, but it works normally, when I noticed that I decided to keep a terminal open with a dmesg -w and a kernel crash happens and prints a stacktrace, but with proton6 no problem, game continues to work, with proton7 it crashes, I think it is the same kernel crash, it’s just that proton6 can deal with it while proton 7 not.
For the wine / truedrive I did not invest time investigating it, I think internet in the wine/prefix that runs truedrive is fine, but have to dig more.
Yeah, it’s a warning for an out of bounds value - 16bit to 8bit in hid-core - which just prints a call stack for easier tracking of the issue, I guess. It is one of the fields (loop_count) of the HID report that starts ffb effect. SDL sends 0xFFFF (16bit) while the HID report requires 8bit - ie. 0xFF. It’s harmless. Eventually they crop it to 8bit and send it that way to the device.
The problem is that thousands such messages are logged per gaming session. I already have a fix for this, which will submit to winehq next week. Hopefully they’ll accept it and then backport to Proton also.
For Proton 7, the issue is somewhere in Wine’s SDL backend, since hidraw works and probably evdev as well.
Oh, so this is somehow related to this?
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:00 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
[Sat Oct 1 13:01:01 2022] hid-generic 0003:16D0:0D61.0011: output queue full
proton:/home/slemke #
I get a lot of those per session:
proton:/home/slemke # dmesg -T |grep -c 'output queue full'
4670
proton:/home/slemke #I saw these once, but couldn’t provoke them again. None of the sims with high ffb rate (BeamNG, rF2, AMS2, ACC, etc.) cause such warnings with the Linux PID driver. I think they are related to one of the out of bounds warnings (value 302) caused by Proton 6.3. This warning is not raised when Proton 7 is running.
I will add here what I think is relevan, just in case it may help:
[ 4445.320267] ------------[ cut here ]------------
[ 4445.320267] WARNING: CPU: 18 PID: 16338 at ../drivers/hid/hid-core.c:1432
implement+0x141/0x150
[ 4445.320270] Modules linked in:
(...)
[ 4445.320319] Call Trace:
[ 4445.320319] <TASK>
[ 4445.320320] hid_output_report+0x12d/0x170
[ 4445.320322] usbhid_submit_report+0x178/0x3e0 [usbhid 43572dc9cc8ffc2e3442fbe8fca6cce6c769061c]
[ 4445.320326] pidff_upload_effect+0x8b/0x610 [usbhid 43572dc9cc8ffc2e3442fbe8fca6cce6c769061c]
[ 4445.320328] input_ff_upload+0x127/0x2d0
[ 4445.320330] evdev_ioctl_handler+0x7a8/0xb20
[ 4445.320333] __x64_sys_ioctl+0x8f/0xd0
[ 4445.320334] ? syscall_trace_enter.isra.20+0xa9/0x1e0
[ 4445.320336] do_syscall_64+0x58/0x80
[ 4445.320338] ? evdev_ioctl_handler+0x6c/0xb20
[ 4445.320340] ? __x64_sys_ioctl+0xae/0xd0
[ 4445.320342] ? syscall_exit_to_user_mode+0x18/0x40
[ 4445.320343] ? do_syscall_64+0x67/0x80
[ 4445.320344] ? exc_page_fault+0x67/0x150
[ 4445.320346] entry_SYSCALL_64_after_hwframe+0x61/0xcb
[ 4445.320348] RIP: 0033:0x7f364008bc27
and:
proton:/home/slemke # uname -r
5.14.21-150400.24.21-default
That’s the usual raceroom with proton6, like I said, a lot of those I can see on dmesg but the game works normally (I think a small stutter when the kernel crash happens).
Dunno if that would be something to report upstream as my system is quite ‘specific’ and with workarounds.
It’s not a crash, just a warning with a call trace. The relevant part should be slightly above the first line of the quote. I’ve fixed the issue with Wine/Proton 7’s SDL backend (the 32bit out of bounds issue). There seems to be another issue with Proton 6, something like: value 302 out of 8bit bounds, etc. This probably won’t be fixed, since it’s a legacy version.
Anyway, once they accept a patch that enables the hidraw backend for SC devices, all these issues will disappear. This is also the only way for R3E to work on Proton 7, since the Sector 3 devs set the SC2’s rotation angle programmatically through direct access to the device. So it crashes in hidapi.dll, if there is no such access. (Proton 6 has this enabled by default, while it’s dinput implementation relies on SDL - a completely different winebus architecture from Proton/Wine 7.)
Hello!
Do you have the MR of that patch? I would like to follow up and try R3E with Proton7 when that gets merged/accepted/released. Or just update this thread when/if that happens.