Same problem also for me on Logitech G29. No buttons or input is working. Other vice plays fine on controller.

System Information

GPU: GTX 3070ti
Kernel version: 6.17.7-arch1-1 (64-bit)
Proton version: 10-3
Wheel-driver: new-lg4ff 0.5.0

Edit

For me I can also bind the buttons in the game. Just the axis that are not detected or bindable

I'm on a Moza R3 bundle and while I can map the buttons no axis is being detected at all so no pedals or steering. Tried a few different proton versions and tweaks to no effect.

I can confirm the same issue on a Logitech G920, tried multiple Proton version with no luck. Good luck

Can't bind axis of Moza R12 and CRP Pedals. Button works fine.

With the T300RS with hid-tmff2 drivers same issue as above, some buttons / axis get detected by game others not.

Not work for me with openffboard wheel, other games like AC, ACC and ACE work perfecty

PDP brand xbox controller is not recognized by game. Tried proton experimental and hotfix.

Same as others reported above, I can't bind axis (wheel and pedals) on a T300RS, all the other buttons are working. On Windows I can bind everything just fine.

Can confirm the same symptoms on a Logitech G29 as well. Can map buttons, but not the wheel or pedals.

Can confirm the same on T300RS, no axis detected, no pedals detected. Buttons mappable. Tried different workarounds but no dice.

Am on Moza R5 bundle, axis are not being detected whatsoever. Buttons seem to assign, but I can't navigate menus.

I was able to get axis binds working on a g29 by passing PROTON_ENABLE_HIDRAW=0x046d/0xc24f to Proton. But there is zero FFB. I tried checking with ffbtools but there arent any FFB events being sent.

Was able to get pedals, wheelbase, steering wheel buttons/shifter all detected and wheelbase FFB working by using Proton 6.3-8. Not ideal as newer versions are more performant, but it's at least fully playable.

Can confirm it works with Proton 6.3-8, but the game is way laggier and the FFB feels a bit off on my G29. I had to delete the local game files at ~/.local/share/Steam/steamapps/compatdata/3917090/pfx/dosdevices/c:/users/steamuser/AppData/Local/acr though, otherwise the game crashed before getting to the main menu.

Sad. I had to go to a different path, but even deleting ~/.local/share/Steam/steamapps/compatdata/3917090/pfx/drive_c/users/steamuser/AppData/Local/acr/* resulted in CTD with proton 6.

@talkingerbil maybe try reinstalling the game from scratch. In my case I think it was an issue with the config I had, that's why deleting the local game files solved the issue

@talkingerbil maybe try reinstalling the game from scratch. In my case I think it was an issue with the config I had, that's why deleting the local game files solved the issue

Even reinstalling, i still crash before reaching the main menu using proton 6

Latest detects my wheelbase (simucube 2) and FFB works, it does not detect my pedals (simgrade VX-Pro) or handbrake (arduino based).

Proton 6.3-8 works for me, but I lose FFB, but as other have said, it runs terribly and crashes after a couple of minutes.
7.0-1 crashes on startup (I get some mono missing errors).
6.3-7 doesn't detect inputs.

Tried a few GE proton releases around the same version and none of them work either (don't detect inputs).
I wonder what specifically was changed in 6.3-8.

All inputs and FFB work fine in windows 11.

Only one button detected on my T248. Otherwise, he works perfectly with other racing game.

Using 6.3-8. I tried deleting .local/share/Steam/steamapps/compatdata/3917090/pfx/dosdevices/c:/users/steamuser/AppData/Local/acr but I still get a crash on startup just before the main menu appears.

There was an old issue affecting FFB on RBR with wine - https://bugs.winehq.org/show_bug.cgi?id=52714 Not sure if it is relevant

Any other ideas on how to get 6.3-8 working? Thanks

Proton 6.3-8 works fine for me. I have Moza R5 and both axes and FFB work fine. I also had crashes. but passing "-dx11" without the quotes as a launch option seemed to have fixed that for me. The only issue is that server connectivity doesn't work. It's not too big of an issue in this game however, because the only "multiplayer" element is the leaderboard.

With Proton Experimental online works just fine, so it must be something with the old Proton 6.3..

Deleting acr, using Proton 6.3-8 with -dx11 got Moza R12 working for me, except I can't bind the clutch or Moza handbrake.

There was an old issue affecting FFB on RBR with wine - https://bugs.winehq.org/show_bug.cgi?id=52714 Not sure if it is relevant

As of ACR, it doesn't seem to react to changing FFB axes count through SDL, as RBR did... It seems we're dealing with something else there.

I have managed to get my G29 working with this wine-proton patch: https://gist.github.com/davidaf3/77d34da3664262accf797c8f0478c7c4.

It might work for other G29s, but not for different wheels. These are the steps I followed in case anyone is interested in reproducing them for their wheel:

1. Make sure the game recognizes your wheel's axes when hidraw is enabled.
2. Get the raw HID report descriptor for the wheel. This descriptor is the one ACR sees when using hidraw, so it contains the input format needed for the game to recognize the wheel's axes. In the case of my G29, it also contains an output with a vendor specific usage that DirectInput doesn't understand. The game uses DirectInput to send FFB effects, that's why FFB doesn't work with hidraw.
3. Get the HID report descriptor that wine sends when hidraw is disabled. This descriptor contains outputs that DirectInput understands. You can get this report descriptor from the Proton logs.
4. Make a new HID report descriptor that combines de inputs of the raw descriptor and the outputs of the descriptor generated by wine.
5. Force wine to send the new report descriptor.
6. Modify the HID input reports generated by wine to match the format of the new descriptor.

My patch also fixed the direction of the FFB effects that was being set to a wrong value when using the new descriptor.

I haven't figured out yet why the game doesn't recognize the wheel axes by default. DirectInput recognizes them, but ACR doesn't seem to be using DirectInput to read the wheel state. I think the issue is on the game's side. Let's hope they fix it soon.

I have managed to get my G29 working with this wine-proton patch: https://gist.github.com/davidaf3/77d34da3664262accf797c8f0478c7c4.

Amazing!

Can confirm that the patch works for me in proton-10.3. Just had to remember to disable the PROTON_ENABLE_HIDRAW launch option.

Thanks for sharing

Proton 6.3-8 works great with the logitech pro wheel in G923 compatibility mode via new-lg4ff-dkms driver, however I couldn't get the external handbrake(connected via usb) to work with this proton. Other than that FFB, pedals, buttons - all functions without problems.
I noticed that with this proton game automatically starts in DX11 mode as mangohud shows DXVK. There might be occasional hitches during shader compilation of new sections of the stage.
Overall decent experience.

EDIT: Forgot to mention that at least with this proton I wasn't able to get DLSS to work, however the game looks quite sharp with the default TSR upscaling.

With Proton-6.3-8 my wheel axis (Moza R12) works fine but the pedals that were working fine before (T-LCM), which are not connected through the wheel base, stopped working.

Nevermind, adding ENV{ID_INPUT_JOYSTICK}="1" to the udev rules for the pedals fixed detection on Proton-6.3-8. Weird that this doesn't seem to be required with later versions of Proton.

using t300rs, hid-tmff2 driver.

on Windows, and proton 6.3-8, all devices are recognized and inputs are registered (except hat switches), and FFB works. I think it's game's(or unreal engine's) bug.

on proton-ge 10-26
without PROTON_ENABLE_HIDRAW, analog axes are not registered while buttons are registered (also hat switches don't work), while FFB works(?). (I'm not sure who is responsible for this. maybe both game and wine.)

with PROTON_ENABLE_HIDRAW=0x044f/0xb66e, all input devices (wheel, shifter, handbrake) are not recognized.
I dumped the Windows driver's HID report descriptor, and found that it has 396 bit padding at the end of report 0x07, while hid-tmff2 has 4 bit. So I tried to apply this patch:

diff --git i/src/tmt300rs/hid-tmt300rs.c w/src/tmt300rs/hid-tmt300rs.c
index 00eecee..32acee4 100644
--- i/src/tmt300rs/hid-tmt300rs.c
+++ w/src/tmt300rs/hid-tmt300rs.c
@@ -128,6 +128,8 @@ static u8 t300rs_rdesc_nrm_fixed[] = {
        0x75, 0x04, /* Report size (4) */
        0x81, 0x42, /* Input (Variable, Absolute, NullState) */
        0x65, 0x00, /* Unit (None) */
+       0x76, 0x8c, 0x01, /* Report size (396) */
+       0x95, 0x01, /* Report count (1) */
        0x81, 0x03, /* Input (Variable, Absolute, Constant) */
        0x85, 0x60, /* Report ID (96), prev 10 */
        0x06, 0x00, 0xff, /* Usage page (Vendor 1) */

It didn't work. But it worked when I switched the size and report count.
This patch on hid-tmff2 driver fixed device recognition and analog axes registration.

diff --git i/src/tmt300rs/hid-tmt300rs.c w/src/tmt300rs/hid-tmt300rs.c
index 00eecee..32acee4 100644
--- i/src/tmt300rs/hid-tmt300rs.c
+++ w/src/tmt300rs/hid-tmt300rs.c
@@ -128,6 +128,8 @@ static u8 t300rs_rdesc_nrm_fixed[] = {
        0x75, 0x04, /* Report size (4) */
        0x81, 0x42, /* Input (Variable, Absolute, NullState) */
        0x65, 0x00, /* Unit (None) */
+       0x75, 0x01, /* Report size (1) */
+       0x96, 0x8c, 0x01, /* Report count (396) */
        0x81, 0x03, /* Input (Variable, Absolute, Constant) */
        0x85, 0x60, /* Report ID (96), prev 10 */
        0x06, 0x00, 0xff, /* Usage page (Vendor 1) */

I think this is a bug in Wine (different behavior from Windows with an incomplete(?) HID report descriptor).

But hid-tmff2 is missing output HID report descriptor so the FFB doesn't work.

HATs are axes as well, that explains why they do not work

yeah, t300rs dpads are hat switches, but the game only allows assigning buttons on some input entries, such as menu navigations. it's game's bug.

Maybe the game doesn't recognize analog axes with a signed range (-32768 ~ 32767) (Linux gamepad spec, Windows xinput spec, Wine SDL converts to signed range), only recognizing unsigned range (0 ~ 65535), while other games recognize both signed (correct) and unsigned (for compatibility) range?

edit: no it recognizes it well when I present the game with a modified HID descriptor.

It's something different. Again, the input plugins in UE5 rely on multiple sources and don't use Directinput as the basis for axis input. They should normally be used for things like raw input for X/Y of a mouse pointer but if the devs don't really know what they're doing, they will use it for simracing stuff.

This patch on Wine 10 fixes axes not being registered when HIDRAW is disabled. FFB works well, too.
The problem is gone if I change the axis size of Wine's generated HID report to 16-bits from 32-bits.

Proton 6.3.8 provides 16-bit axes, so the game worked fine.

diff --git i/dlls/winebus.sys/hid.c w/dlls/winebus.sys/hid.c
index ee1c9a9de07..aab9ccc29e2 100644
--- i/dlls/winebus.sys/hid.c
+++ w/dlls/winebus.sys/hid.c
@@ -268,13 +268,13 @@ static BOOL hid_device_add_axis_count(struct unix_device *iface, BOOL rel, BYTE
         ERR("axes should be added before buttons or hatswitches!\n");
     else if ((state->bit_size % 8))
         ERR("axes should be byte aligned, missing padding!\n");
-    else if (state->bit_size + 32 * count > 0x80000)
+    else if (state->bit_size + 16 * count > 0x80000)
         ERR("report size overflow, too many elements!\n");
     else if (rel)
     {
         if (!state->rel_axis_count) state->rel_axis_start = offset;
         state->rel_axis_count += count;
-        state->bit_size += 32 * count;
+        state->bit_size += 16 * count;
         return TRUE;
     }
     else
@@ -292,7 +292,7 @@ static BOOL hid_device_add_axis_count(struct unix_device *iface, BOOL rel, BYTE
 
         if (!state->abs_axis_count) state->abs_axis_start = offset;
         state->abs_axis_count += count;
-        state->bit_size += 32 * count;
+        state->bit_size += 16 * count;
         return TRUE;
     }
 
@@ -314,9 +314,9 @@ BOOL hid_device_add_axes(struct unix_device *iface, BYTE count, USAGE usage_page
     };
     const BYTE template[] =
     {
-        LOGICAL_MINIMUM(4, min),
-        LOGICAL_MAXIMUM(4, max),
-        REPORT_SIZE(1, 32),
+        LOGICAL_MINIMUM(2, min),
+        LOGICAL_MAXIMUM(2, max),
+        REPORT_SIZE(1, 16),
         REPORT_COUNT(1, count),
         INPUT(1, Data|Var|(rel ? Rel : Abs)),
     };
@@ -1461,21 +1461,27 @@ void *hid_device_create(const struct hid_device_vtbl *vtbl, SIZE_T size)
 # define LE_ULONG(x) ((ULONG)(x))
 #endif
 
+#ifdef WORDS_BIGENDIAN
+# define LE_USHORT(x) RtlUshortByteSwap((USHORT)(x))
+#else
+# define LE_USHORT(x) ((USHORT)(x))
+#endif
+
 BOOL hid_device_set_abs_axis(struct unix_device *iface, ULONG index, LONG value)
 {
     struct hid_device_state *state = &iface->hid_device_state;
-    ULONG offset = state->abs_axis_start + index * 4;
+    ULONG offset = state->abs_axis_start + index * 2;
     if (index >= state->abs_axis_count) return FALSE;
-    *(ULONG *)(state->report_buf + offset) = LE_ULONG(value);
+    *(USHORT *)(state->report_buf + offset) = LE_USHORT(value);
     return TRUE;
 }
 
 BOOL hid_device_set_rel_axis(struct unix_device *iface, ULONG index, LONG value)
 {
     struct hid_device_state *state = &iface->hid_device_state;
-    ULONG offset = state->rel_axis_start + index * 4;
+    ULONG offset = state->rel_axis_start + index * 2;
     if (index >= state->rel_axis_count) return FALSE;
-    *(ULONG *)(state->report_buf + offset) = LE_ULONG(value);
+    *(USHORT *)(state->report_buf + offset) = LE_USHORT(value);
     return TRUE;
 }

edit: fixed wrong offset calculation.

Can confirm @foriequal0's patch works on my G29 too! And way simpler than my patch. It seems the issue is that the game doesn't recognize 32 bit axes after all.

@davidaf3 I corrected some mistakes in the patch.

Hmm, so any device with defined 32bit axis by default is not recognised by the game at all?

Hmm, so any device with defined 32bit axis by default is not recognised by the game at all?

It's not that the device has a 32 bit axis, it's because wine creates a "virtual device" with all axes set to 32 bits. That virtual device is the one the game sees unless you enable hidraw. That's why the wheel works with hidraw enabled.

Okay! 16 bit is quite fine. @foriequal0 would you send this to Wine and create a MR to upstream or would you like for some of use to take care of that?

Most devices still show their range as 16 bits so making the field 16 bit shouldn't matter. Virutal devices always have 16 bit signed range so it's even more of a no-brainer This seems like a slam dunk victory and honestly, kudos for getting that.

it's because wine creates a "virtual device" with all axes set to 32 bits

Of course, but i was talking more about Windows. It seems that game already has numerous issues with device detection on Windows, and my guess is these 'problematic' devices also exporting 32bit fields...

@Lawstorant Thank you! I'm trying to create an MR to upstream by myself.
I'm following this guide: https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches
I'll create a PR with the patch as is first, then follow their review.
I'll link the PR here once it's created, so you can join there if you'd like.

Another confirmation. I compiled the above patch into proton-ge-custom and all my devices work perfectly now. OpenFFBoard wheel, Heusinkveld Ultimate+ pedals, and simlab xb1 . Thanks!

It would be nice to get some confirmation from windows users to see if the game behaves the same way there (I suspect it does). It might explain the inconsistency with device functionality. Also if we were to report it in some concise way with evidence from windows testing it might get fixed pretty easily and then no patch would be necessary. I have no clue how to do that though.

There's already someone with OSW wheel that confirmed this helping on Windows.

I confirm the above patch got the axes detected and the FFB working in the title. The DPAD aren't properly recognized though.

Probably needs further changes as dpad is defined as hat axes as well.

https://gitlab.winehq.org/wine/wine/-/merge_requests/9789 I've created the MR in Wine. @Lawstorant

I think the DPAD problem should be either addressed by the game itself (the game should support HAT axis as DPAD input)
or outside the Wine (proton would have PROTON_USE_HAT_AS_DPAD=1 or use modified protopedal like software to map HAT axis to dpad buttons)

I added a comment under your patch. I think you forgot about unsigned values :D

Latest patch to the game (0.2) fixed axis inputs. Now axis are bindable even on non-patched Proton versions, i tested with experimental.

Improved overall steering wheels support. (We will keep improving the codebase until all steering wheel and sim-racing peripherals are fully supported and working)
Improved FFB

Added Hat Switch (e.g. directional buttons) support for steering wheels
Added double gear up/down inputs
Added possibility to bind Neutral gear on steering wheels

So, you mean the game is fully playable without having to do anything other than install it and play it with the default Proton, and I'll be able to use my G29 without any problems?

If so, I'll buy it tomorrow!

T300RS has no problem with default Proton. I think it'll be fine for G29 too.
But their hat switch support has bug... 😢

I think they couldn't properly implement 32 bit axis support too on Windows.
But I suppose it's fine on Linux since Wine relies on SDL and it normalizes the input to 16 bits anyway.

So real 32bit input axes are still broken?

@Lawstorant I can't confirm that, I don't have 32bit hardware.

Anyway, this will fix the hat switch problem.
Here's the MR on Wine: https://gitlab.winehq.org/wine/wine/-/merge_requests/9796

diff --git a/dlls/winebus.sys/hid.c b/dlls/winebus.sys/hid.c
index 82f73759e73..d09395dce52 100644
--- a/dlls/winebus.sys/hid.c
+++ b/dlls/winebus.sys/hid.c
@@ -230,8 +230,8 @@ BOOL hid_device_add_hatswitch(struct unix_device *iface, INT count)
     {
         USAGE_PAGE(1, HID_USAGE_PAGE_GENERIC),
         USAGE(1, HID_USAGE_GENERIC_HATSWITCH),
-        LOGICAL_MINIMUM(1, 1),
-        LOGICAL_MAXIMUM(1, 8),
+        LOGICAL_MINIMUM(1, 0),
+        LOGICAL_MAXIMUM(1, 7),
         REPORT_SIZE(1, 4),
         REPORT_COUNT(4, count),
         UNIT(1, 0x0), /* None */
@@ -1531,33 +1531,33 @@ BOOL hid_device_set_button(struct unix_device *iface, ULONG index, BOOL is_set)
 /* hatswitch x / y vs value:
  *      -1  x +1
  *     +-------->
- *  -1 | 8  1  2
- *   y | 7  0  3
- *  +1 | 6  5  4
+ *  -1 | 7  0  1
+ *   y | 6  f  2
+ *  +1 | 5  4  3
  *     v
  */
 static void hatswitch_decompose(BYTE value, ULONG index, LONG *x, LONG *y)
 {
     value = (index % 2) ? (value >> 4) : (value & 0x0f);
     *x = *y = 0;
-    if (value == 8 || value == 1 || value == 2) *y = -1;
-    if (value == 6 || value == 5 || value == 4) *y = +1;
-    if (value == 8 || value == 7 || value == 6) *x = -1;
-    if (value == 2 || value == 3 || value == 4) *x = +1;
+    if (value == 7 || value == 0 || value == 1) *y = -1;
+    if (value == 5 || value == 4 || value == 3) *y = +1;
+    if (value == 7 || value == 6 || value == 5) *x = -1;
+    if (value == 1 || value == 2 || value == 3) *x = +1;
 }
 
 static void hatswitch_compose(LONG x, LONG y, BYTE *value, ULONG index)
 {
     BYTE new_value = 0;
-    if (x == 0 && y == 0) new_value = 0;
-    else if (x == 0 && y < 0) new_value = 1;
-    else if (x > 0 && y < 0) new_value = 2;
-    else if (x > 0 && y == 0) new_value = 3;
-    else if (x > 0 && y > 0) new_value = 4;
-    else if (x == 0 && y > 0) new_value = 5;
-    else if (x < 0 && y > 0) new_value = 6;
-    else if (x < 0 && y == 0) new_value = 7;
-    else if (x < 0 && y < 0) new_value = 8;
+    if (x == 0 && y == 0) new_value = 0x0f;
+    else if (x == 0 && y < 0) new_value = 0;
+    else if (x > 0 && y < 0) new_value = 1;
+    else if (x > 0 && y == 0) new_value = 2;
+    else if (x > 0 && y > 0) new_value = 3;
+    else if (x == 0 && y > 0) new_value = 4;
+    else if (x < 0 && y > 0) new_value = 5;
+    else if (x < 0 && y == 0) new_value = 6;
+    else if (x < 0 && y < 0) new_value = 7;
 
     if (index % 2)
     {

Release 0.2 Is out now seem to solve the input issue.

No improvement with PDP xbox controller on 0.2. Doesn't get recognized at all. No buttons, no axes, nothing.

You can just plug pedals into the wheelbase or, if that's the case now, plug them in separately

I couldn't find any relationship between axis's report size (8, 16, 32), signess (signed/unsigned), range and offsets (signed balanced, signed positive, partial positive, unsigned positive, ...) by modifying the HID report on the fly on modified Proton, all worked fine.

It might be a different issue then. I observed some issues before when the HID descriptor has weird shape of padding (insufficient padding size, 376 bits padding instead of 376 count 1 bit padding, etc.) on Linux Proton.

still no ffb on r9 with v0.2. Anyone got it working with latest proton or patch?

A question about Assetto Corsa Rally Events. ... Is it normal that they don't connect and send the time to the server? Does this only happen on Linux, or does it also cause an error on Windows?

A question about Assetto Corsa Rally Events. ... Is it normal that they don't connect and send the time to the server? Does this only happen on Linux, or does it also cause an error on Windows?

It's a common issue, they don't seem to have much in the way of server resources right now.

Compatibility Report
Name of the game with compatibility issues: Assetto Corsa Rally
Steam AppID of the game: 3917090

System Information

GPU: RX 6700 10GB
Distro: Cachyos
Kernel version: 6.18.2-3
Drives: Mesa 25.3.2
Proton version: Experimental

Symptoms: Game crashes randomly sometimes, happened with different graphics aswell so i dont know what is exactly causing the problem.

Logs:

steam-3917090.log

Compatibility Report

• Name of the game with compatibility issues: Assetto Corsa Rally

System Information

• GPU:RTX 2060 6GB NVK
• Video driver version: Mesa 26.1.0 git
• Kernel version: 6.18.8
• Link to full system information report as [Gist]https://gist.github.com/pollux78/0cc678c4474d328a989a0589f5e557a4
• Proton version: Proton Experimental
• LOG: steam-3917090.log

Symptoms

Game will freeze when trying to load into the game menu

Reproduction

1. Use latest mesa git not nvidia proprietary driver
2. Try and load into the main menu
3. Watch it crash

I have an issue where when there is force feedback active before pausing the game the wheel will lock to either left or right with full force when I pause. It's also happening in assetto corsa evo and dirt rally 2.0 (probably in many more games) and only when using proton from version 10.0 and up. I tested standard proton, GE and cachyos in both games and all have the same issue unless I use proton 9. I have moza r5 base.