Driving Simulator for Vehicle Research

Alfye20 · 3 August 2022 07:10

I hope not to screw up but I think that to change the HID of the SC2 it can be achieved by activating the appropriate axes on TD general tab, so that Windows recognizes it as a steering wheel, not a generic device with only one axis as It comes from factory.

Mika · 3 August 2022 11:10

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.

Xyon_of_Calhoun · 12 August 2022 15:21

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!

Xyon_of_Calhoun · 12 August 2022 21:30

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.

logos · 13 August 2022 07:42

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:

github.com

ValveSoftware/wine/blob/a7618abea5ffeb3bfb1e69c0dbcdc1008bd88163/dlls/winebus.sys/bus_udev.c#L1698


            ntdll_umbstowcs(buffer, strlen(buffer) + 1, desc.serialnumber, ARRAY_SIZE(desc.serialnumber));
    }
#endif


    if (!desc.serialnumber[0])
    {
        static const WCHAR zeros[] = {'0','0','0','0',0};
        memcpy(desc.serialnumber, zeros, sizeof(zeros));
    }


    if (!is_dualshock4_gamepad(desc.vid, desc.pid) && !is_dualsense_gamepad(desc.vid, desc.pid) && !is_thrustmaster_rudder_pedals(desc.vid, desc.pid))
    {
        TRACE("hidraw %s: deferring %s to a different backend\n", debugstr_a(devnode), debugstr_device_desc(&desc));
        close(fd);
        return;
    }
    if (is_sdl_blacklisted(desc.vid, desc.pid))
    {
        /* this device is blacklisted */
        TRACE("ignoring %s, in SDL blacklist\n", debugstr_device_desc(&desc));
        return;

Here is how they do it for Thrustmaster T.Rudder Pedals:

Don’t forget to allow the hidraw user acces for SC2 in Linux

.

Berniyh · 15 August 2022 13:51

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!

logos · 16 August 2022 01:58

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.

Berniyh · 16 August 2022 08:23

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.

Berniyh · 18 September 2022 09:05

@Mika: any update on testing the new descriptor?

Mika · 18 September 2022 11:30

It should work on Linux when we get a next release out

Berniyh · 18 September 2022 14:24

Awesome, thanks a lot!

And also thanks a lot to @logos for finding the right path.

S.R.Lemke · 22 September 2022 20:22

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 regedit and add the Enable SDL mentioned 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.

logos · 23 September 2022 05:02

@S.R.Lemke,

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.

S.R.Lemke · 23 September 2022 09:05

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!

logos · 23 September 2022 10:43

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

S.R.Lemke · 23 September 2022 14:48

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.

logos · 24 September 2022 05:07

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/

S.R.Lemke · 24 September 2022 14:17

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)

logos · 24 September 2022 16:01

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.

S.R.Lemke · 26 September 2022 17:49

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)