This is false. Those axis are always included in the HID report, but if unconfigured, they always report 0.
Changing the HID descriptor is something I will have a look at next week when back at the office.
Affecting the game controller / steering wheel aspect of device detection is not possible without writing a fully custom USB device driver.
I’d be very interested in this patch! I took a peek at the proton source to see if I could figure it out, but I can’t see where they’re selectively permitting the hidraw backend, ie where I’d need to make a change.
That said, I also can’t get the TrueDrive paddock to run under Proton 7 either; I don’t know if that’s related, since it’ll see the wheelbase but via SDL and maybe get confused, but it just hangs when I load it up. I can get it to see the wheelbase under Proton 6, but naturally get no FFB under there for the other reasons you already mentioned. Happy to be a guinea pig for trying things out!
I posted this, rebuilt my usbhid module with the patches and modprobed it, and it… works? Somehow? With assetto Corsa running under proton 6 (the only proton version I can get it to work properly in). I’m a bit confused how I managed this.
Yep, proton 6 is using either SDL or evdev as a backend, so the FFB will work through the Linux HID PID driver (once it’s patched and starts recognizing SC2 as an FFB device). Proton 7 also uses SDL as a backend, so it should work the same way. Probably there is a mismatch in the registry keys left from the previous version, which confuses proton 7. I’d suggest deleting (or backing up) the old prefix ‘pfx’ folder, and starting from scratch, since there are too many changes between the versions. Unfortunately for AC this also means installing .NET 4.7 again 
.
On my system proton 7 works properly through SDL with the patched usbhid.
To enable the hidraw backend for SC2, you’d need to add it here:
Here is how they do it for Thrustmaster T.Rudder Pedals:
Don’t forget to allow the hidraw user acces for SC2 in Linux .
Thanks logos for the explanation. I do now understand a bit better the mechanics at work.
Uhm, well, this won’t work. It says “Press any button in the controller to activate the chosen effect.”
That’s a tough task if your controller doesn’t feature any buttons (being connected). 
But I do get effects listed, which I think is a good thing?
This is not the case if “Enable SDL” is set to 1.
(And that is “Enable SDL” with a space, not “EnableSDL” as suggested by you previously and as suggested on a couple of sites on the net.)
But your hints allowed me to test some other FFB device I own, a Brunner CLS-E joystick.
That one unfortunately doesn’t expose HID FFB, but using hidraw access and disabling the SDL backend, I have been able to connect it (finally!) to the control software using wine.
And it works with the linux plugin for X-Plane 11, so overall it seems working (haven’t tested everything).
To me that proves that your basic setup is working, I just can’t easily test it with the SimuCUBE yet. So thanks a lot for that! 
Hehe, didn’t think about that! 
But having all the effects listed with the hidraw backend (“Enable SDL” set to 0) proves that the HID PID device is properly recognized and responds to the specific PID output reports.
Also, not having FFB effects with the SDL backend turned on, means that the Linux FFB PID driver is unable to control the Simucube (which we know is the case currently ).
Yes, with a space. I think I wrote it that way in my posts. Sorry for not being more specific, as this can be really confusing.
This is a great device! I have a VKBSim Gunfighter Mk.III for flight simming, but Brunner is just in another level! If you are able to control it through the control software, then there is a chance FSX/FS2020 and P3D plugins also working in Wine.
Can you try the SC1’s controlling software in the winepreffix? It should work exactly as Windows. If you choose profiles with different degrees of rotation or damping, etc., it’ll be immediately obvious whether the wheel responds to these commands.
I’m doing almost only helicopters and for that it is magnificent, much better than any “regular” joystick I’ve tried, the precision at which you can give input is incredible.
So far, I haven’t even used it for its FFB purposes, but solely because I can define the force-response curve. And that for helicopters really is key to success.
Well, and having proper force trim is a nice addon, too. 
Sorry, I only use XP11 (native) and DCS (via wine nowadays). I might try with DCS, but tbh getting FFB working isn’t really my top prio. The main reason why I care for getting the CLS2Sim software working is to be able to select a non-default profile, because unlike the Simucube, you need to keep the software online, otherwise it’ll switch back to default.
Yes, that does work. I haven’t tried every option in the tool, but switching profiles works and the settings of the servo control change as desired.
It should work on Linux when we get a next release out
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.
wine regedit and add the Enable SDL mentioned 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"
wine truedrive_installer.exe
that is basically where I stoped for now.
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
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.
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.
