Driving Simulator for Vehicle Research

logos · 28 July 2022 12:55

Wine 7, which was released in the beginning of the year, added support for HID PID devices. This allows Wine to control such devices directly, bypassing the Linux FFB driver (along with all other params as deadzone, fuzz, etc.) completely. So for the FFB to work, it needs the hidraw backend in winebus.sys enabled for the used wineprefix, as well as hidraw user access granted for SC2 on the Linux side.

All sims (rF2, AMS2, ACC, AC, R3E, PC2, BeamNG, etc.) work properly, as well as all kinds of controlling apps (TrueDrive, SimHub, etc.). I’ve been using my SC2 this way for more than a year without any problems. Subjectively the FFB between Windows and Wine feels the same (or very similar).
Objectively I did some tests incl. FFB rate measuring, comparison of HID reports (whether the values are similar and in range, the sequence of reports, etc.), and didn’t find any issues.

As I had some experience with the HID PID specification, and really like my SC2 , so I pushed some patches to upstream Wine to help them in the implementation, and to iron out some bugs. Tested everything on the SC2, as they didn’t have any other PID FFB devices, so we may say that the PID implementation in Wine is developed with SC2 in mind .

The hidraw backend in your wineprefix can be enabled through the registry value “Enable SDL” in [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus], which must be added with right click->New->DWORD value, and set to “0” (turn off SDL, so devices can be enumerated by the hidraw backend).
To start regedit:

WINEPREFIX=“path to your wineprefix” wine regedit

The hidraw user access for SC in Linux can be enabled by placing a file “72-simucube.rules” in “/etc/udev/rules.d/” with the following content:

# Simucube 1; USB
KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d5a”, MODE=“0660”, TAG+=“uaccess”

# Simucube 2 Sport; USB
KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d61”, MODE=“0660”, TAG+=“uaccess”

# Simucube 2 Pro; USB
KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d60”, MODE=“0660”, TAG+=“uaccess”

# Simucube 2 Ultimate; USB
KERNEL==“hidraw*”, ATTRS{idVendor}==“16d0”, ATTRS{idProduct}==“0d5f”, MODE=“0660”, TAG+=“uaccess”

For Proton 7.0/SteamPlay the things are a little bit more complicated, since they enable selectively the hidraw backend only for some devices, which is hardcoded in the source. I plan to push a patch, which would add the SC devices and some others as Fanatec CS pedals (which would allow apps that use Fanatec SDK to control the pedal buzz function, as R3E, etc.).

On the Linux side for native apps, already @Berniyh posted what is needed. I have some patches that make those missing “Usages” optional. Have been thinking to submit them upstream, but the Linux maintainers are very strict, so it’ll need a lot of time to explain the need of such changes. I’ve fixed also some bugs, which would be easier to push upstream.
BTW, there is no need to compile the whole kernel for this. The code (hid-pidff.c) is in the “usbhid” driver, which can be installed as a dkms driver, and make the process fully automatic. It would allow using the kernels that come with your distribution, etc.
For the hwdb changes (deadzone, fuzz, etc.) that @Berniyh posted, as well as hidraw access, i guess those can be pushed relatively easy to systemd upstream. So they would arrive automatically on the users’ systems, when the various distributions install the next version of systemd.

I noted, when helping the PID development in Wine, that there are some issues with the HID report descriptor, which might be preventing the hid parser in Windows to properly parse those report descriptions. Here is an excerpt from the “Set Effect Report” part:

Usage (21h),
Collection (Logical),
Report ID (1),
Usage (22h),
Logical Minimum (1),
Logical Maximum (40),
Physical Minimum (1),
Physical Maximum (40),
Report Size (8),
Report Count (1),
Output (Variable),
.
.
.
Usage (57h),
Collection (Logical),
Usage (000A0001h),
Usage (000A0002h),
Unit (Degrees),
Unit Exponent (-2),
Logical Minimum (0),
Logical Maximum (180),
Physical Minimum (0),
Physical Maximum (36000),
Unit,
Report Size (8),
Report Count (1),
Output (Variable),
Unit Exponent (0),
Unit,
End Collection,
Usage Page (PID),
Unit (Seconds),
Unit Exponent (-3),
Logical Minimum (0),
Logical Maximum (32767),
Physical Minimum (0),
Physical Maximum (32767),
Report Size (16),
Report Count (1),
Unit,
Unit Exponent (0),
End Collection,

(Sorry for the not properly indented text, but I couldn’t find a way to add spaces or tabs, it always cuts them to one space )

In the collection “Direction” (usage 57h) there are declared two indexed usages 000A000(1|2)h, which aren’t reflected by the same number report counts with output (var). Till the end of the “Direction” collection there is one report count with output, and till the end of the collection “Set Effect Report”, there is another one without output (I believe this is from your tests with the “Start Delay” usage). So the Windows parser probably gets confused by the lacking report count and tries to add the next report count from the supposedly added “Start Delay” usage, just to find out that the unit is in seconds, while it expects degrees for “000A0002h”, etc.
IMO the solution here is to set the report count inside the collection “Direction” (57h) to 2, which will properly reflect the number of the declared usages in the collection. This will free the Windows parser to parse the next “Start Delay” (0xA7) usage when added.
The Wine test suite, which they run on Windows machines to confirm validity of their work, includes a virtual HID PID driver, which declares “Start Delay”, as well as the other missing usages, without any problems for Windows accepting them and interacting with the driver.

The other missing usages are from the “Set Condition Report” (0x5F) - “Negative Coeficient” (0x62) and “Dead Band” (0x65). The Linux driver currently just disables the condition reports entirely, if it doesn’t find those usages. The “Negative Coeficient” (0x62) can be added after “Positive Coefficient” (0x61) as a second usage with just the same parameters, and only the report count increased to 2. The “Dead Band” can be added at the end.

@Mika, can I contact you through PM? Don’t want to make this post any longer . I have a specific question about one of the HID reports, and also have found another issue with one of the games, which I believe needs fixing on the Fw side.

Mika · 28 July 2022 13:40

Thanks for the informative post! Of course you can PM. I will only be able to react and do tests at our end the week after next week.

Berniyh · 28 July 2022 17:33

Wow, thanks for the detailed investigation and report.

I remember trying to access the SC1 and also other devices using the new hidraw driver, but I never got this to work and ultimately gave up because the documentation on it was so old and unhelpful.
Guess I should try again.

One question though: shouldn’t hidraw be the default for the newer Wine versions?

logos · 28 July 2022 22:40

The default is still SDL, although all the backends have been completely reworked around HID. Both SDL and evdev build virtual HID report descriptors internally, so they look like native HID devices to the rest of the (pseudo) driver chain - hidclass.sys - and Wine/Windows.
The best thing is the Wine devs choose PID for the FFB implementation. So if the device has FFB axes, those backends (SDL and evdev) expose also PID reports at their virtual HID descriptors. Hidraw just exposes what it sees natively - the whole HID report descriptor, and all input, output and feature reports just going through to/from the Linux hidraw interface.
Then the real HID PID implementation is in dinput.

So it still needs “Enable SDL” disabled, to allow hidraw to enumerate the devices. There is one catch though - if the devices don’t have hidraw user access granted, then the winebus.sys will fallback to the evdev backend, as SDL is already disabled. Evdev is the native Linux interface for such devices, so it should work fine.
I’d recommend granting hidraw user access for all your hid devices - pedals, button boxes, joysticks - and using the hidraw backend, which would allow most of the controlling software for those devices to function properly.

Proton 7.x had hidraw as default backend, but recently they choose to enable it selectively for certain devices.

logos · 29 July 2022 10:40

@Mika
For more clarity I’m attaching the HID report descriptor of SC2 Sport, in a text file properly indented, where the issue is immediately clear:
SC2_descr.txt (53.9 KB)

The issue is on the row 206 (in the “Set Effect Report” (21h)):
“Report Count” should be set to 2 for the two declared Usages in the collection “Direction” (57h), since the output is variable.
This would allow adding “Start Delay” at the end of the “Set Effect Report”, and Windows properly parsing and accepting the report descriptor, IMO.

For the “Set Condition Report” (5Fh):
The missing “Negative Coefficient” (0x62) Usage can be added after row 292, and then on row 293 “Report Count” changed to 2.
The missing “Dead Band” (0x65) Usage can be added at the end of the report description.

IMO those two missing fields in the condition report could be the cause of issues that some users have with the DirectInput Condition effects. Both can make things feel different if the developer used them.

I mentioned TrueDrive in my previous post, so would like to confirm that it works flawlessly on Wine with the hidraw backend enabled. Both paddock and offline. Enabling/disabling high torque, setting/changing options, working with profiles (creating, editing, deleting), etc., all works without issues. Even the wheel rotation graphic has a slight lag, exactly as Windows .
The only feature I haven’t tested is flashing the firmware, since it’s a potentially dangerous move. So everyone, please flash your firmware on a Windows machine/VM, where the things are tested and it is safe to do.
Of course there are some other caveats - for example you can’t run it as easy on boot - that option won’t work the same way on Linux, etc.

Berniyh · 31 July 2022 12:27

Hm, I can’t get it working. Do you maybe know a simple tool to test FFB on Windows?
I tested with AC and somehow didn’t work. Since I made the changes using protontricks I’m very sure that I changed the appropriate prefix. I’m also sure that I changed/checked the correct hidraw device.
Also, is it really “Enable SDL”? Asking, because the registry entries usually don’t have a space.
Nevertheless, I tested with both settings and it just doesn’t work.
In addition, I played with the “Start” setting in the winebus registry group, as suggested here
https://wiki.winehq.org/Hid
to be sure, but that also didn’t help. (original setting was 3, changed it to 2)

logos · 2 August 2022 08:29

@Berniyh
It won’t work on proton, as they have made it selectively allow devices with certain VID/PIDs for the hidraw backend. So the “Enable SDL” winebus.sys value doesn’t work there. I’m planning to push a patch which would enable Simucube, as well as other devices that would benefit from hidraw access. Hidraw was initially the default backend for proton, but few months ago they changed it to the way it works now.
It uses SDL for all other devices, so it needs the Linux PID FFB driver to work properly (which must be patched to recognize the Simucube as a PID device ).

For testing the FFB on Wine/Proton, just use WINEPREFIX=“the path to the prefix” “path to the wine binary” control. Then open the “Game Controllers” item and choose “Test Force Feedback” tab.

The “Enable SDL” value works on Wine/Wine Staging, though. I’m using Wine Staging with Steam (for Windows) installed in a WINEPREFIX. Can be done easily with Winetricks. Using it this way, since it’s easier for development (pushing patches to upstream, experimenting things, etc.). rF2 also had much higher FPS in Wine Staging with Steam (Windows), than on Proton with Steam (Linux). I believe they fixed the issue some time ago, although cannot be sure (haven’t played it on proton recently).

So the technology is there, with the last touches on the Wine PID implementation made with SC2 in mind . We just need to put the final pieces together to make it work out of the box.

For example:
If/When GD fixes the HID report descriptor and adds the missing usages, the Linux PID driver will recognize the Simucube as it is (without any changes needed). This way the FFB on Simucube would work out of the box for Proton (SDL backend) and any native Linux app.

If/When Proton devs accept the patch I’m planning to push for the hidraw access of Simucube, Proton would use the HID PID implementation in Wine, directly controlling the device through the hidraw Linux interface, etc., etc.

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.