I would like to say this has been bugging me ever since i have switched to linux! Having the exact same issues, with proton 6.3-8 the ffb effects work well but after about 2 minutes most textures disappear (the weird dxvk bug). With newer versions this does not happen, but the ffb effects are totally gone. Like OP i can bind the wheel and the game notices it has force feedback capabilities (the ffb options menu unlocks in the controls menu), but the effects themselves are just not working. I am also using Logitech G29. I have not found a workaround for this.

+1 to the reports above. Using Latest wine or GE-Proton I do not have force feedback, even though it works with other proton games. I was not able to run the game with older wine versions.

UPDATE: seems all logitech wheels are affected. it is likely its possible due to registry problem

This sounds eerily familiar to BeamNG.drive's FFB issue which didn't work in proton past 6.3-8. Very recent Proton versions allow setting the update type to "Full" see https://github.com/ValveSoftware/Proton/issues/1237#issuecomment-1666583259 . I have no clue whether adjusting FFB output like this is even possible on RBR, I couldn't see a way to do it, however maybe it might lead us closer to a solution?

UPDATE: seems all logitech wheels are affected. it is likely its possible due to registry problem

What registry problem?

I don't know, reportedly there are some steering wheels that have problems even on Windows. RSF provides registry fixes for them:
registry.zip

I can only guess that doesn't apply with wine since that doesn't exist in the registry on older wine either.
Do those registry keys tell dinput what effects the device is capable of?

I have a hunch that it might be something to do with no axis's being reported to the game. If you open up the ffb tool fedit.exe it can't find any axis on newer versions of wine.

Is the new dinput backend for wine SDL? Does anyone know a way to see how SDL reports the axis and how to change it?

As a little tip: You can update the dxvk version used by proton. I've just copied and overwrite all files from
steamapps/common/Proton 7.0/dist/lib/wine/dxvk/ and
steamapps/common/Proton 7.0/dist/lib64/wine/dxvk/
to thier respective places in steamapps/common/Proton 6.3/

Now FFB works and I saw no trees disappear.
Thanks for this issue report.

@AlexanderWKoenig What version of RSF (if any) are you running? The latest one 1.44.9 seems to have a page fault for me in Proton 6.3 . If I use a newer proton it will launch, however FFB is not working.

wineserver: using server-side synchronization.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
004c:fixme:virtual:NtQueryVirtualMemory (0xffffffffffffffff,0x229880000,info_class=1000,0x229887008,8,(nil)) Unknown information class
004c:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\nsiproxy": c0000003
0034:fixme:service:scmdatabase_autostart_services Auto-start service L"nsiproxy" failed to start: 87
0188:fixme:heap:GetNumaHighestNodeNumber semi-stub: 00000000006BEFD8
wine: Call from 000000007BC34538 to unimplemented function KERNEL32.dll.GetProcessGroupAffinity, aborting
wine: Unhandled page fault on read access to 000000000000000C at address 0000000001185B94 (thread 0188), starting debugger...
Unhandled exception: page fault on read access to 0x0000000c in 64-bit code (0x0000000001185b94).
Register dump:
 rip:0000000001185b94 rsp:00000000006bd170 rbp:00000000006befa0 eflags:00010202 (  R- --  I   - - - )
 rax:00000000003b0230 rbx:00000000006bd1c0 rcx:0000000000000130 rdx:0000000000000000
 rsi:00000000006bee70 rdi:00000000006bdbb0  r8:00000000000003df  r9:0000000019930520 r10:0000000000000005
 r11:00000000006bd440 r12:0000000000000000 r13:00000000006bd2e8 r14:00000000006befa0 r15:00000000006bdd18
Stack dump:
0x00000000006bd170:  00000000006bdd18 00000000006befa0
0x00000000006bd180:  0000000001285380 000000007b0724d7
0x00000000006bd190:  00000000006bf030 0000000001377ce3
0x00000000006bd1a0:  0000000000000004 00000000006bd470
0x00000000006bd1b0:  00000000006bee70 00000000015b7f20
0x00000000006bd1c0:  0000000000000000 0000000001283ec0
0x00000000006bd1d0:  0000000000000000 00000000012a22aa
0x00000000006bd1e0:  0000000000000000 00000000015b7f20
0x00000000006bd1f0:  00000000006bdbb0 0000000001283e01
0x00000000006bd200:  00000000006bd2e8 00000000006bee70
0x00000000006bd210:  00000000006bdd18 00000000006bd470
0x00000000006bd220:  00000000006be970 0000000001286350
Backtrace:
=>0 0x0000000001185b94 EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006befa0)
  1 0x0000000001377ce3 EntryPoint+0xf6262() in coreclr (0x00000000006befa0)
  2 0x00000000012a22aa EntryPoint+0x20829() in coreclr (0x00000000006befa0)
  3 0x0000000001286350 EntryPoint+0x48cf() in coreclr (0x00000000006bd470)
  4 0x0000000001285495 EntryPoint+0x3a14() in coreclr (0x00000000006bd470)
  5 0x000000007bc58379 EntryPoint+0xffffffffffffffff() in ntdll (0x00000000006bd470)
  6 0x00000000011adf26 EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006bf331)
  7 0x000000000125350f EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006bf331)
  8 0x00000000012534a5 EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006bf331)
  9 0x00000000012533f8 EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006bf331)
  10 0x000000000126542a EntryPoint+0xffffffffffffffff() in coreclr (0x00000000006bf331)
  11 0x0000000000cb3fa0 EntryPoint+0xffffffffffffffff() in hostpolicy (0x00000000006bf480)
  12 0x0000000000cc8878 EntryPoint+0xffffffffffffffff() in hostpolicy (0x00000000006bf7a9)
  13 0x0000000000cca6ef EntryPoint+0xffffffffffffffff() in hostpolicy (0x00000000006bf7a9)
  14 0x000000018000b720 EntryPoint+0xfffd0def() in hostfxr (0x00000000006bf7a9)
  15 0x000000018000e39a EntryPoint+0xfffd3a69() in hostfxr (0x00000000006bf8c9)
  16 0x00000001800108d6 EntryPoint+0xfffd5fa5() in hostfxr (0x0000000000000001)
  17 0x000000018000ea04 EntryPoint+0xfffd40d3() in hostfxr (0x00000000006bfab1)
  18 0x0000000180008473 EntryPoint+0xfffcdb42() in hostfxr (0x0000000000000001)
  19 0x0000000140012a80 in rsf_launcher (+0x12a7f) (0x00000000006bfd00)
  20 0x0000000140012dfb in rsf_launcher (+0x12dfa) (0x0000000000000001)
  21 0x00000001400142a8 in rsf_launcher (+0x142a7) (0x0000000000000000)
  22 0x000000007b62c9a9 EntryPoint+0xffffffffffffffff() in kernel32 (0x0000000000000000)
  23 0x000000007bc5e5f3 EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000000000)
0x0000000001185b94 EntryPoint+0xffffffffffffffff in coreclr: movl       0x000000000000000c(%rdx),%eax
Modules:
Module  Address                                 Debug info      Name (36 modules)
PE                cb0000-          d14000       Export          hostpolicy
PE               1120000-         1618000       Export          coreclr
PE              7b000000-        7b0d7000       Deferred        kernelbase
PE              7b600000-        7b812000       Export          kernel32
PE              7bc00000-        7bc9e000       Export          ntdll
PE             140000000-       14004d000       Export          rsf_launcher
PE             180000000-       180060000       Export          hostfxr
PE             1c8db0000-       1c8e3d000       Deferred        msvcrt
PE             1cd860000-       1cd868000       Deferred        api-ms-win-crt-utility-l1-1-0
PE             1d97a0000-       1d97a7000       Deferred        api-ms-win-core-fibers-l1-1-1
PE             21a7e0000-       21a855000       Deferred        setupapi
PE             231ae0000-       231b62000       Deferred        rpcrt4
PE             23d820000-       23da47000       Deferred        user32
PE             241850000-       241857000       Deferred        api-ms-win-crt-environment-l1-1-0
PE             262250000-       262259000       Deferred        api-ms-win-crt-runtime-l1-1-0
PE             26b4c0000-       26b642000       Deferred        gdi32
PE             2739c0000-       273af6000       Deferred        oleaut32
PE             28ba60000-       28ba67000       Deferred        api-ms-win-crt-time-l1-1-0
PE             2e3540000-       2e3591000       Deferred        shlwapi
PE             2e8f10000-       2e9028000       Deferred        ole32
PE             2f1fa0000-       2f1fad000       Deferred        version
PE             30a2c0000-       30a2c9000       Deferred        api-ms-win-crt-stdio-l1-1-0
PE             30c980000-       30c988000       Deferred        api-ms-win-core-synch-l1-2-0
PE             3126f0000-       312709000       Deferred        shcore
PE             327020000-       327072000       Deferred        combase
PE             32a700000-       32a729000       Deferred        sechost
PE             330260000-       33029f000       Deferred        advapi32
PE             33ea00000-       33ea09000       Deferred        api-ms-win-crt-string-l1-1-0
PE             344840000-       344848000       Deferred        api-ms-win-crt-filesystem-l1-1-0
PE             350a30000-       350a39000       Deferred        api-ms-win-crt-convert-l1-1-0
PE             355100000-       355107000       Deferred        api-ms-win-crt-locale-l1-1-0
PE             360a80000-       360a8a000       Deferred        api-ms-win-crt-math-l1-1-0
PE             39b510000-       39b518000       Deferred        api-ms-win-crt-heap-l1-1-0
PE             3af670000-       3af728000       Deferred        ucrtbase
PE             3afd00000-       3afd1a000       Deferred        imm32
PE          7f0ede420000-    7f0edecf7000       Deferred        shell32
Threads:
process  tid      prio (all id:s are in hex)
00000030 services.exe
        00000034    0
        00000038    0
        00000044    0
        00000048    0
        00000060    0
        00000114    0
        0000012c    0
        0000015c    0
        00000160    0
0000003c winedevice.exe
        00000040    0
        0000004c    0
        00000050    0
        00000054    0
00000058 winedevice.exe
        0000005c    0
        00000064    0
        00000068    0
        0000006c    0
        00000070    0
        00000074    0
        00000078    0
        0000007c    0
        00000080    0
        00000084    0
        00000088    0
        0000008c    0
        00000090    0
        00000094    0
        00000098    0
        0000009c    0
        000000a0    0
        000000a4    0
        000000a8    0
        000000ac    0
        000000b0    0
        000000b4    0
        000000b8    0
        000000bc    0
        000000c0    0
        000000c4    0
        000000c8    0
        000000cc    0
        000000d0    0
        000000d4    0
        000000d8    0
        000000dc    0
        000000e0    0
        000000e4    0
        000000e8    0
        000000ec    0
        000000f0    0
        000000f4    0
        000000f8    0
        000000fc    0
        00000100    0
        00000104    0
        00000108    0
0000010c plugplay.exe
        00000110    0
        00000118    0
        0000011c    0
        00000120    0
00000124 svchost.exe
        00000128    0
        00000130    0
        00000134    0
00000138 tabtip.exe
        0000013c    0
        0000017c    0
        00000180    0
00000140 explorer.exe
        00000144    0
        00000148    0
        0000014c    0
00000154 rpcss.exe
        00000158    0
        00000164    0
        00000168    0
        0000016c    0
        00000170    0
        00000174    0
        00000178    0
00000184 (D) C:\games\Richard Burns Rally\rsf_launcher\RSF_Launcher.exe
        00000188    0 <==
        0000019c    0
0000018c conhost.exe
        00000190    0
System information:
    Wine build: wine-6.3
    Platform: x86_64
    Version: Windows 10
    Host system: Linux
    Host version: 6.1.64-1-lts

@kevenwyld I used this lutris install script as a base for what to do:
https://lutris.net/games/install/23410/view

So I should have 1.02 Patch + FixUps Plugin. The RBR Version I use was from archive.org: https://archive.org/details/richardburnsrally-pc-redump

Tested it yesterday and still works fine. I had to select "detect devices" in the option menu to show the force feedback option.

I am facing the same issue with FFB not working in newer Proton versions. I am playing the vanilla game v1.02 with no mods installed.

It's probably an upstream Wine issue, not Proton-specific, since I primarily use Lutris and the following versions I tried were affected:

• lutris-7.2-2
• Wine 8 from official Debian 12 repos (8.0~repack-4)
• lutris-GE-Proton8-15
• wine-ge-8-22
• wine-ge-8-25

With Wine v<7 (lutris-6.14-4) and DXVK v<2 (v1.10.3, v2 doesn't work with older Wine versions) I am able to play the game with both working FFB (using G25 and the new-lg4ff kernel module) and trees not disappearing.

There's a new DirectInput joystick backend using the improved HID stack to
communicate with winebus.sys and host devices. This backend supports
force-feedback effects using the standard HID Physical Interface Device
reports

In the wine 7 release notes, found at least some reports of grand prix legends no longer working, personally I tested only the rallysimfans release of RBR and also tried to edit the registry files to add my wheel , but only got crashes.

Games that loose FFB for me when going > version 7 are:

• Beam.ng
• Automobilista 1

Maybe the games affected are NOT using HID interfaces and this means the FFB advertisement is not reaching them / they cant enumerate any FFB capable device, no idea how to debug and report this unfortunately.

I'm having the same issue with Fanatec GT DD Pro wheel. Wheel works great with RBR except FFB.
With proton below 7 the game doesn't start. I'm using RSF (rallysimfans) version of RBR.
FFB works fine in Automobilista 2 and proton experimental.

I can confirm that using proton 6.3 and manually updating the dxvk dlls works perfectly. I hope this bug is resolved since playing through lutris I can track time, which I like to do. I wasn't able to get an older version of wine to work through lutris.

PS: can also confirm that @kevenwyld 's fix works, and I now have FFB working while playing through lutris. It does involve modifying the runner installation so I selected a wine version that I wasn't using for anything else and dedicated to it.

I can confirm that using proton 6.3 and manually updating the dxvk dlls works perfectly. I hope this bug is resolved since playing through lutris I can track time, which I like to do. I wasn't able to get an older version of wine to work through lutris.

PS: can also confirm that @kevenwyld 's fix works, and I now have FFB working while playing through lutris. It does involve modifying the runner installation so I selected a wine version that I wasn't using for anything else and dedicated to it.

If you rename the folder of that Lutris Runner to something like RBRWine Lutris will pick it up and you can reinstall the other version if you ever need it.

The game tries to change the number of axes of an event. Disallowed by the API but Windows seems to simply ignore this request whereas in Wine it results in the method call failing.

There's longer explanation in the upstream Wine bug 52714 with an attempted workaround/fix attached. The patch applies to Proton too (tested against experimental)

Autocenter is still broken in current Proton but works in upstream Wine. Hopefully it will work again with Proton 9.

Awesome. I tried the patch today. Works great.

Good to hear it's very close to being fully sorted out. I won't be able to test it with Logitech wheel, since I have Thrustmaster TMX now, but I hope it will also work

Autocenter is still broken in current Proton but works in upstream Wine. Hopefully it will work again with Proton 9.

Since Proton 7 there are problems with the steering wheels that in 6 there were not and they have not done anything to solve them by Valve (to my knowledge). Apparently it is not an exclusive problem of this game. Semms that they touched something and since then there are problems.

If somebody wants to try I have compiled Wine 9.7 with the above mentioned patch and for me ffb is working (Thrustmaster T150RS).

Details ---> https://gitlab.com/as400l/wine-rbr

Thanks for this work! I don't understand why this patch is not included on the newest versions of Wine and Proton

@leillo1975 maybe we should reply to that winehq thread confirming that the patch works and for what wheel it works. I am going to do this now.
Just remember that it may not work for in-game controller force feedback test. But it works on special stages.

This night I will try it, and then, if it works in my G29, I will post it on https://bugs.winehq.org/show_bug.cgi?id=52714

@leillo1975, ok thx. I just submitted my report there. Fingers crossed :)

Otherwise we will have to keep special Wine version for older games. As far as I know not only RBR is affected.

Thanks for this work! I don't understand why this patch is not included on the newest versions of Wine and Proton

I thought perhaps it was because no one was on the cc list for that bug but I posted on the other big FFB bug and no one has got back yet. They are probably just stretched a bit thin over there.

I wrote the patch in the upstream bug.

Thanks for testing the patch! A couple of points:

• The type of steering wheel doesn't matter for this particular bug. Wine/Proton rejects the effect offhand and it is never played back by the hardware. There could of course be other, hardware dependent bugs still affecting the game.

• Knowing if the patch breaks (or fixes) force feedback in other games would be helpful!

My knowledge of force feedback doesn't extend much beyond the "makes steering wheel go brrr" so I can't really push for the patch to be submitted as-is in either Wine or Proton. I'm hoping for a real developer to step in and provide a proper fix.

It works really great with this wine patched build. Thanks again!

@whizse - thanks for writing the patch. It really makes this game soooo much better :) I hope more people will test this in different games. Otherwise we will have to maintain separate branch of wine just for RBR.
And compiling wine is a big PITA ! :)

@leillo1975 - thx for reporting !

Using hid-fanatec custom kernel module with a Fanatec CSL DD , RBR will now try to rip my arms of my torso. 😈

Not sure if I can launch steam games without a proper proton build , so unsure if other games will work.

A little late to the party, but I can confirm the patch works with the build from @as400l and a Logitech G923 Xbox/PC edition combined with RBR-RSF. (Fedora 39 + usb_modeswitch setup; Bottles; non-working runner as counter-test: caffe-9.7)

Has anyone got VR working? Maybe this has something to do with #6808?

Has anyone got VR working? Maybe this has something to do with #6808?

Not with open composite but with steamvr openRBRVR works.
https://github.com/Detegr/openRBRVR

@whizse, I confirm the patch works with Moza R12. Based on the binaries in this thread.

Just a quick report about a test I did using protopedal:

• created a virtual controller with only 1 axis for steering and 2 buttons (paddle shifter)
• disabled my real wheel in wine control
• set up axis as control and arrow key to accelerate
• force feedback worked in wine 10

I guess RBR is not sending the bogus effects message when there IS no Y axis , but somehow if I map more axes , its always enumerated to Y axis , even when specified otherwise, mixing both , the real and "fake" device doesnt seem to read anything except "Y-AXIS" when setting controls , weird.

EDIT: after several times removing the detected "Y-AXIS" binding, I could map my normal controls -> FFB with wine 10
That was my config to test this, PINKIE/TOP2 somehow are my paddle shifters , I think 1 button has to be mapped, otherwise the device would not show up in wine control.

protopedal --name fanateque --vendor 2121 --product 2121 \
-a X -s X \
-b PINKIE -s PINKIE \
-b TOP2 -s TOP2 \
--no-auto-axes --no-auto-buttons --ffb-log /tmp/ffb.log \
--verbose /dev/input/by-id/usb-Fanatec_FANATEC_Wheel-event-joystick

For setting up the correct X axis , there is a --grab parameter , RBR will see both devices , but then only react tho the fake one, after this restarting and mapping the rest without --grab should work

I'll repost my comment from Wine Bugzilla. TL;DR this is an issue with the game itself, not Wine/Proton

Tomasz Pakuła 2025-02-20 08:49:17 UTC
I've done extensive testing and debugging with @JacKeTUs and this is an issue with the game, not wine. Wine works as expected and removing these checks would be in clear opposition to how directinput works. The same issue is present on windows.

1. The game creates FFB effects incorrectly. It includes ALL the FFB-enabled axes found on a device but then tries to change cAxes to 1, rgdwAxes to only contain the steering axis and rglDirection to only contain one entry. This is in clear violation of directinput which clearly states that cAxes, rgdwAxes and rglDirection can't be changed once they have been set during effect creation. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee417536(v=vs.85)

   NOTE from linked documentation:
   The cAxes and rgdwAxes members cannot be modified once they have been set. An effect always has the same axis list.

2. The same issue (no FFB) is present on windows. A lof of PID wheelbases (Moza, VRS, Cammus etc) expose two possible FFB axes in their descriptors. The registry fix/hack from Moza (and later adapted by RSF for other manufacturers) overrides directinput and tells it that a specific device only has one FFB enabled axis. directinput in Wine doesn't have this functionality as it's pretty arcane.

3. @JacKeTUs created a small program to test effect creation and updates and we confirmed that there's no way to change cAxes once it has been set with the effect creation. In every possibility (changing direction types, supplying different axes etc) Wine behaves and returns the same errors as Windows AND works properly wit the same configs that work on Windows. Any change to cAxes will always return DIERR_INVALIDPARAM.

The game worked previously as directinput emulation was very rudimentary. Now, that it's much, much closer to 100% replicating Windows, these game bugs are surfacing.

Why would it not work with known working devices like Logitech G29? I'm trying to get a hold of data from one to confirm but Logitech does a lot of custom work in their windows drivers which expose different HID descriptors to what's actually found on the devices. They might actually expose two FFB axes. Maybe it's something in the driver/SDL/Wine handling of virtual joysticks that exposes more than the one FFB axis.

I just want to emphasize that this is not the device's or Wine's issue/problem. A single-axis effect should be created with just one axis from the start.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee417536(v=vs.85)#single-axis-effects

If possible, it would be best to fix game/rsf ngp FFB effect creation.

@Lawstorant

Tomek - thanks for your work guys !

Now, when I think about it, it could really be the game problem. People were reporting similar problems on Windows.

As to fixing the game itself:

1. I'm not sure if they can do it (no access to source code).
2. People running RSF on Linux are treated there like complete nerds. Experienced this myself few times. The only reply I got was something like "throw your Linux box out of the window" :)

So realistically - we need to run RSF with patched Wine when we want FFB to work.

The same issue (no FFB) is present on windows. A lof of PID wheelbases (Moza, VRS, Cammus etc) expose two possible FFB axes in their descriptors. The registry fix/hack from Moza (and later adapted by RSF for other manufacturers) overrides directinput and tells it that a specific device only has one FFB enabled axis. directinput in Wine doesn't have this functionality as it's pretty arcane.

There is some page in an unrelated game settings (dirt4) that I found by accident, it listed the axis reporting force feedback as X/Y , so how is wine actually getting the values from the linux driver?
There could be an option to tweak those to just report the X axis as FFB supported ones, in my case this would be hid-fanatec that did heavy lifting of the newlg4ff code (and maybe just reports the same stuff?)

The game worked previously as directinput emulation was very rudimentary. Now, that it's much, much closer to 100% replicating Windows, these game bugs are surfacing.

...actually found on the devices. They might actually expose two FFB axes. Maybe it's something in the driver/SDL/Wine handling of virtual joysticks that exposes more than the one FFB axis.

With my CSL DD , I briefly threw in an old windows 10 install , and no matter the registry fixes etc. FFB did not work once in RBR, so the assumption may be correct that only wheels with hacky drivers make the game work at all.

~There are also ffbtools to "wrap" ffb commands and report different capabilities, have to look into this if its easy just to clamp the amount of axis reported as FFB supported as a more simple fix.~ Ah , forgot , its advertised in the device descriptor.

EDIT: @Lawstorant any information if the "test FFB page" in wine control should actually work since the new direct input implementations, besides gamepads, this does not work at all with my wheel since forever ?

how is wine actually getting the values from the linux driver?

From the PID descriptor
https://github.com/wine-mirror/wine/commit/1285bbfa43c6db32dba3cafedb3bc3ca99046a85

There are also ffbtools to "wrap" ffb commands

ffbwrap works on Linux level. Wine throws an error much earlier, because game uses wrong cAxes numbers.

we need to run RSF with patched Wine when we want FFB to work.

Patched Wine which removes this kind of checks could lead to multiple problems, starting with page exceptions. When Wine changing directions as per DIEP_DIRECTION, it first checks if size of lDirection array is the same and then memcpy whole array. If sizes are not the same, we could get some unfortunate bugs. Best course of action would be to use protopedal and wrap whole device to the one axis.

There could be an option to tweak those to just report the X axis as FFB supported ones.

Device descriptor define that. Game should do proper work of choosing correct axis and maintain number of them in one effect. Current "registry fixes" aka "compatibility mode" uses old deprecated way for telling dinput driver which axis are which, and removes FFB flags (DIDOI_FFACTUATOR) from other axis but the X, as far as we can tell from tests. Sadly, documentation seems to already lost and if somebody has the description what does OEMData field actually do, we would be grateful.

So realistically - we need to run RSF with patched Wine when we want FFB to work.

I find protopedal a much cleaner approach to hide Y axis from RBR. I'll ask the devi if there could be a possibility of stripping FFB info from a given axis without removing it completely.

any information if the "test FFB page" in wine control should actually work

I'd have to check what it actually does and what effect it uses. From what I can gather, RBR creates a constant force effect as soon as it detects an FFB joystick and never again. In my whole 50 MB log from wine, the effect creation happens only once.

so how is wine actually getting the values from the linux driver?

UPDATE: https://github.com/ValveSoftware/Proton/issues/6702#issuecomment-2671327920

It doesn't. Linux FFB api could be considered incomplete and I started working on extending it. There's currently no way to send device control commands, get effect status (playing/stopped), no info about FFB-enabled axes. There's no way of using just one axis for an effect (Axes Enable vs Direction Enable). It was still a great effort for how good it still works while being created more then 20 years ago when gaming on linux was pretty much a joke.

I'm currently upstreaming massive upgrades to the generic USB PID driver to be more compatible and support Moza, Cammus, VRS, PXN etc. Then I'll tackle FF api and current limitation of max 80 buttons on joysticks (I want to create a completely new input event to circumvent the need for defined KEY usages).

People running RSF on Linux are treated there like complete nerds. Experienced this myself few times. The only reply I got was something like "throw your Linux box out of the window" :)

I shared my findings with NGP developer, but let's say his response wasn't enthusiastic.

@Lawstorant @JacKeTUs

I fully agree that protopedal approach would be much better than modifying wine source.

Tomek - if you could provide some instructions on how to use it (after contacting dev ofc) I'd be very grateful. And not only me I guess :) Until today I didn't even know such software exists.

Thank you both once more !

@as400l Right now you could do just this

protopedal /dev/input/by-id/usb-path_to_your_device-event-joystick -a X --no-auto-axes --grab

in separate terminal, before launching the game
This will create second device with the same name but only with one axis.

@JacKeTUs, ok will try and report here. Now where is unmodified Wine :)

Update ad. Logitech wheel working on Windows but not in Wine

I was combing through the Wine and SDL code and figured out why these wheels, which should work, still seem to fail at the same check.

SDL has this function in linux haptic (force feedback handling):

static bool SDL_SYS_HapticOpenFromFD(SDL_Haptic *haptic, int fd)

It sets the SDL force feedback data like this:

// Set the data.
haptic->hwdata->fd = fd;
haptic->supported = EV_IsHaptic(fd);
haptic->naxes = 2; // Hardcoded for now, not sure if it's possible to find out.

haptic->naxes is the member that holds the number of FFB-enabled axes. They are not matched to anything, just straight number. Now, for issues.

1. It's hardcoded to 2 as there's currently no way to get this info from Linux API. That's why all FFB wheels will not work by default with RBR in wine.

2. Even if devices defines its FFB axes for say X and Z, or Rx, Ry, or for example more than 2, this will only ever expose two axes. And they will be always the first and second (X, Y). I need to check if this is Wine or SDL that changes the axes as if device only has Rx, Ry, Rz, they will appear as X, Y, Z in Wine. For X, Z, RX, it will be X, Y, Z etc.

3. Devices which only have one axis, will appear to have two FFB axis in SDL BUT Wine sets the FF_ACTUATOR axis flags when looping over them on device init thus one axis device will only have one FFB axis in Wine -> RBR now works.

In summary, without Wine hacks which won't ever be upstreamed (and shouldn't be), protopedal (and other tools) will only work if we leave just the steering axis on the device. This, of course, is sub-optimal.

While updating/extending FFB api in linux could even make it to upstream this year, then we have to update SDL to handle this, and maybe add a hint to limit the number of FFB axes on demand. If a fix could be possible in RBR/NGP plugin, it could be fixed next week :D

In the meantime, I'll see if I could maybe add a hint to SDL that will allow us to overwrite naxes for a given VID:PID on demand. Setting it to 1, would fix RBR + it could be implemented as a game fix in proton.

Bad news guys, it seems that not only SDL hardcodes two FFB axes, but wine does this as well.
https://gitlab.winehq.org/wine/wine/-/blob/wine-10.1/dlls/winebus.sys/hid.c?ref_type=tags#L940

Here, you can see that that PID_USAGE_AXES_ENABLE has two axes defined. I'll have to work to make this dynamic, based on the value coming from SDL.

Which is not exposed to third parties... Yeah, it will take a lot of time to get all this sorted out in Linux, SDL, Wine. Protopedal / patched wine will be the meta for the foreseeable future.

EDIT:
I'm stupid. It is exposed and has been from SDL 2.0

@JacKeTUs so to report here. I've tried this:

protopedal /dev/input/by-id/usb-path_to_your_device-event-joystick -a X --no-auto-axes --grab

The game does not detect wheel is moving.

Check if the X axis is really the one for steering :)

Good news!

I've managed to successfully modify SDL and Wine to create an arbitrary umber of FFB axes. I had some issues with FFB not working when device only had one axis, but found some other hardcoded parts in Wine :P

I can confirm that I successfully ran RBR with FFB without using protopedal to hide existing axes from the game, which means all the axes were usable.

I hope all goes well with Wine and we'll be able to use SDL_JOYSTICK_HAPTIC_AXES="0xFFFF/0xFFFF/1" to fix all of our wheels soon enough. Yes, I added a "wildcard" VID:PID pair to easily incorporate this in Lutris installers, maybe in proton fixes :D

@Lawstorant - this is quick big time ! Any idea in which versions that could be included ?

And I tried wine 10.2 - seems like it breaks RBR completely (running wow64).

Wine 10.3 at the earliest if it goes well. SDL 3.2.6 / 3.4.0. I'm trying to maybe push this into SDL2 as well as this isn't changing any APIs. (Wine uses SDL2 but it works with SDL2-compat as well)

• [x] SDL3 https://wiki.libsdl.org/SDL3/SDL_HINT_JOYSTICK_HAPTIC_AXES
• [x] SDL2 https://wiki.libsdl.org/SDL2/SDL_HINT_JOYSTICK_HAPTIC_AXES
• [x] Wine https://gitlab.winehq.org/wine/wine/-/merge_requests/7658

Good news!

Okay, life got in the way and writing Wine tests is weirdly hard BUT
Force Feedback now works on linux as of RSF v1.54.0/NGP7 7.5.779!

We did a lot of debugging, searching and it turns out this was a long standing issue that affected wheelbases on Windows as well. Now, FFB works on Linux and on Windows where previously, Moza, Cammus, Asetek etc needed the compatibility fix. It's no longer needed! Workerbee did a great job especially because this fixed FFB for all possible future wheelbases that define two (or more) ffb axes in their descriptor.

No workarouds needed, no variables to set. Just install the newest RSF and (at least this part) will Just Work™

@Lawstorant I don't know how you did it but huge respect to you !

Anyone having an issue where they can't click on or interact with the RBRHUD dialog (accessed by pressing F4) after starting a stage? After starting a stage F4 will make the dialog visible, but the mouse doesn't move and I can't click on it. I also can't access the pacenotes/seat adjustment dialogs which are accessed by double-leftclick and double-rightclick.

I can interact with the RBRHUD dialog before starting a stage just fine.

I normally run the game in gamescope however I have this issue even outside of gamescope. This could be a sway issue, but I am unable to test with another window manager at this time.

archlinux
mesa 25.0.2
CPU: AMD Ryzen 9 5950X
GPU: AMD Radeon PRO W6800
WM: Sway 1.10.1

I've seen a similar report on RSF discord so it might be a bug in the plugin itself as the report was from windows.

This isn't strictly in scope but this is the place where I'm most likely to get a good response. I've been trying to get controller vibration to work in this game (currently don't have access to my wheel). On windows, it seems that the way to do it is to use software such as XInputPlus to forward FFB events as controller vibration events (to my understanding). I tried to get this software to work through wine and got as far as hooking it successfully; it copies a few dinput / xinput dlls that you use dlloverrides with n,b with. However, as the game opens after hearing the beep that the library plays to indicate a successful hook the game gets stuck in the login sequence (where it's supposed to navigate through menus on its own). It might be the case that I messed something up in the process, but when I disable the dll overrides the game works as usual.

So it seems like my options are:

1. use native linux software that does roughly the same thing as XInputLoader (I didn't find any);
2. write my own virtual wheel device that generates vibration. (I can do it, but it's probably not trivial).

Any suggestions?

@kisak-valve

When trying to play Rallysimfans RBR with the RBRVR plugin and trying to use Openxr i get a wineopenxr.dll does not appear to exist.

The dev who maintains the plugin said i needed a 32bit version of openxr to get it working.

I don't use ALVR, but I managed to build a 32-bit version of WiVRn+xrizer, and the openRBRVR plugin works in SteamVR mode with that build. However, I do get the reported error when using that plugin in OpenXR mode.

Arch Linux here. I can't run RallySimFans with a gamepad plugged in. When the game detects my 8BitDo Ultimate 2C controller (be it at startup or plugging it in while it's running) the game will immediately exit.

It's bizarre, but I'm not sure that it's a Proton issue, since this Steam forum post reports very similar symptoms and appears to be a Windows user.

@Firepal I use that same controller on arch linux.

I have additional issue to non-functional FFB in racing games: some games don’t detect my Logitech G923 Xbox/PC and Logitech G27 wheels at all in newer versions or WINE. While in older WINE versions (<8) they are detected by games. Happens in Codemasters titles, which I tested.