We haven’t come up with any documentation on the capabilities and limitations of the Microsoft’s driver, its all by experimentation.
I finally figured out how to match vendor and product ids. File would look like this:
evdev:input:b0003v16D0p0D5A*
EVDEV_ABS_00=:::0:0
(no colon before the last wildcard).
1 Like
Hello, can you inform me how is the situation right now with SC on linux?
It doesn’t seem very good.
I think to achieve this would be relatively not so big of an effort, right now seems the base already holds the driver && settings, and the driver paddock windows apps does some kind of authentication only, if we could skip that authentication with some argument I think we would be closer to see what happens next.
Linux detects it when plugged in currently(dmesg), but dunno if it works and how good if it could connect if that ‘authentication’ could be by passed.
Situation has not changed - there are some fields in the usb interface descriptor that Linux expects there to be for the device to be detected correctly, and when enabled, Windows says that the device cannot be used.
There is no ‘autentication’ mechanism at all, however the API to command the device and its settings is not public.
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.
2 Likes
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.
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?
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.
1 Like
@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.
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)
@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.
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.
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.
1 Like
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 .
1 Like
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! 
1 Like
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.
1 Like