Hello!
I did not have that problem with the game, but my wheelbase and pedals are different.
OpenFFBoard + FreeJoy pedals + GT Neo all connected and detected by the game, without issues. Force Feedback also working.

But i have another issue: graphical artifacts present, look like polygons glitching on car interior, dashes and mirrors
Also tried various graphical settings and RADV_DEBUG=nodcc, without luck.
These artifacts does not appear on any other game, so GPU is not a problem.

Video with artifacts: https://www.youtube.com/watch?v=Yb-y3J-lbbo

Another user with Nvidia GPU reports that game is working without any artifacts.

Looks like Mesa/DKVK issue?

GPU: AMD Radeon RX 6900 XT
Video driver version: Mesa 24.2.8-1, AMDVLK 2024.Q4.3
Kernel version: 6.12.6-1
Link to full system information report as Gist: https://gist.github.com/JacKeTUs/56c34143883c3e2661f30d1e800e5058
Proton version: Proton Experimental, but also tested Hotfix, 8.0-5, 9.0-4, GE-Proton9-22

UPD: I tested with AMDVLK, 2024.Q4.3, artifacts are present as well. Performance is worse, 30fps vs ~120 fps on Mesa
UPD: no changes with new update (0.1.1)
UPD: no changes with new update (0.1.2)

Replying to https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2596293883

I hear the game is working fine on Steam Deck without artifacts, and I believe for other RADV users.

I won't be able to play until I get home, so I will have to test later, but I am using the latest Mesa version (Kisak PPA).

Replying to https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2596293883

I have tested on ChimeraOS same artifacts here. I have a problem with OpenFFBoard the buttons not work very well.
Performance are not the best but i have the minimum hardware required.

Replying to [#8395 (comment)](https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2596293883)

I have tested on ChimeraOS same artifacts here. I have a problem with OpenFFBoard the buttons not work very well. Performance are not the best but i have the minimum hardware required.

In that case, I guess someone could file a bug report to Mesa about this?

Hello

Once I launch the game with my Fanatec CSL DD ... the game spawns the window, then crashes.

This is a known bug which affects a couple of games that come with the FanatecSDK. In short, it seems that the wheel detection of FanatecSDK throws an exception when it finds a compatible wheel but it cannot really talk to it.

This is why I'm working on supporting a hidraw mode for Fanatec wheels, which allows the FanatecSDK to talk to the wheel 'the same way' like in windows, see https://github.com/gotzl/hid-fanatecff/pull/86 and this comment https://github.com/gotzl/hid-fanatecff/pull/86#issuecomment-2365175089. With this branch of the driver, and the posted proton version, I'm able to run ACE and I get FFB/LEDs ...

I confirm same visual artefacts than @JacKeTUs
6950XT with Mesa 24.3.3

And I also confirm that hidraw branch of fanatec driver made by @gotzl makes FFB and LEDs works perfectly

I can also confirm the new fanatec driver makes my wheel work perfectly, with one caveat: it is detected as "Thrustmaster Sim Pedals", so I have two devices using the same name, but one of them are the actual pedals, the other one is my Fanatec wheel. This peculiar issue is also visible in ACC with this Proton version.

I still get a lot of stutter, making the game unplayable completely. I don't see any visual glitches, though.

Once I launch the game with my Fanatec CSL DD ... the game spawns the window, then crashes.

What I think. ACE detects Fanatec gear and auto enables Fanatec SDK (on ACC it's Fanatec LED's (schreenshot bellow). That's why only https://github.com/gotzl/hid-fanatecff/pull/86 works.

Tested with different proton versions, all of them crashes (if Fanatec gear is connected). Without Fanatec, it starts with no issues.
And the biggest issue here, there is no ability to turn OFF Fanatec SDK (Fanatec LEDs).

And I can confirm a lot of stutters. This happens always in the same place on track. For example on Brans Hatch first corner, then third one. On back straight near arch. When stutters happens GPU load drops to zero, and then jumps back to full load.

Just clicked play and the game works but there are graphics issues like these:

Tried running Proton Hotfix and ProtonGE-22, lowest settings and even a different pp filter but the issue still shows up.

After messing with graphics settings it's fine for a couple of seconds and then goes back to having issues again.

System Specs:

More discussion also about my issue on Reddit / other peoples' experience:
https://www.reddit.com/r/linux_gaming/comments/1i2vgb5/graphics_issue_on_ac_evo_with_fedora_linux_nvidia/

Forgot to include this

Is any contributer here able to tell us if the graphical bugs on AMD are a RADV problem or possibly a problem with Proton/vkd3d-proton?

Replying to https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2598384872

You're using an older Nvidia driver, so upgrade to the latest one (in this case, 565) if possible.

I have some graphic artifacts that you can mainly see on the cockpit of the cars. Specially on the mirrors and infotainment area. It also happens on the bonnets from the outside camera.

Operating System: Arch Linux
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.1
Kernel Version: 6.12.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B84
System Version: 2.0

I have no apparent graphics problems, but the performance is very bad with constant stuttering. I'm not sure but I thought I read somewhere that a recent update removed the rare artifacts.

AMD® Ryzen 7 5800x 8-core processor × 16
GeForce RTX 3070 (555)
32GB DDR4 3200

I can see my resource usage go up and I am able to hear the main menu song, but no window appears for me.

11th Gen Intel(R) Core(TM) i7-11800H
GPU: Nvidia RTX 3060 laptop (565.77)
16GB DDR4 3200

proton log: https://gist.github.com/superboss2300/2363cf708613a401347317fada635b13

Had to do this or it wouldn't work:

sudo sysctl --write vm.max_map_count=1048576

Replying to [#8395 (comment)](https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2598384872)

You're using an older Nvidia driver, so upgrade to the latest one (in this case, 565) if possible.

I've updated to the latest production driver 550.144.03 and tried a different map as well and it's still happening.
Using Proton Experimental.

It initially starts off fine

And after some time it's just horrible - for some reason this time it's a completely different effect.

Replying to https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2614578201

Well with games, you're better off with the beta drivers like 565

Losing FFB in Assetto Corsa Evo when at limit (Thrustmaster T300RS)

Issue

When playing Assetto Corsa Evo (early access v0.13) when reaching maximum force the FFB just completely drops to zero (-1 in logs).

For example driving around a corner, when at about the grip limit/getting understeer the wheel instantly loses all FFB for a short period of time (ranging from very short to about a second or so).
Sometimes there was a "knocking" effect where FFB would drop and activate 2-4x a second while driving around a corner.

To avoid reaching maximum FFB it is possible to reduce the ingame FFB strength to about 60-65. This does not work by reducing the FFB gain in Oversteer.

Other games (Assetto Cora/Automobilista 2/native BeamNG.drive) do not have this issue, nor does it occur on Windows.

Logs

The ffbwrap logs show that the force drops to -1 instead of reaching at 32767 (no occurrence of 32767):
FFB_ACE.log-20250126122545_bug.log

000094499695 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:-32614 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000094499701 < 0 id:0
000094502707 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:-31382 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000094502715 < 0 id:0
000094505716 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:-1 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000094505722 < 0 id:0
000094508696 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:-1 attack_length:0 attack_level:0 fade_length:0 fade_level:0

While the log from Assetto Corsa (via Content Manager) does not show this behavior and reaches 32767:
FFB_AC.log-20250126144719_normal.log

000035919049 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:31593 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000035919056 < 0 id:0
000035922066 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:32767 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000035922076 < 0 id:0
000035925110 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:32586 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000035925120 < 0 id:0
000035928067 > UPLOAD id:0 dir:16429 length:0 delay:0 type:CONSTANT level:32767 attack_length:0 attack_level:0 fade_length:0 fade_level:0

How to reproduce

FFB gain 100% in Oversteer and ACE (with Thrustmaster T300RS).
Driving with Mazda MX5 at second gear redlining and steering either fast in a direction or just taking a corner at about the steering limit.

Tried

Changing Proton versions
Installing Thrustmaster driver into prefix
ffbwrap --offset-fix --update-fix

@Pengukov, that issue lies both in game and in wine. And Wine team today approved my patches for this.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7161
https://gitlab.winehq.org/wine/wine/-/merge_requests/7217

TLDR: game doesn't properly scale Magnitude values, and sends values over documented 10k. Wine doesn't properly scale them and returns -1 instead.

Will update my ProtonGE with latest patch version and issue will be resolved in it.

I have a similar problem with Pista Motorsport. I fixed it lowering FFB to 50%. I hope this patches work also with this game

@JacKeTUs just tested your GE-Proton release from last week, seems to be working fine. Guess I'll use that for the time being. Thanks for your work.
@leillo1975 you could also test the release from JacKeTus from here
https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton9-23-FFB

tested your GE-Proton release

It lacks latest fixes for saturation value for condition effects. It will be just enough for correct values, but as you clearly saw, AC Evo may set some values incorrectly 😄

I will update this build soon, but i would call it temporary solution at best.

With 0.1.4 graphical glitches on AMD are not fixed

@JacKeTUs just tested your GE-Proton release from last week, seems to be working fine. Guess I'll use that for the time being. Thanks for your work. @leillo1975 you could also test the release from JacKeTus from here https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton9-23-FFB

I can confirm that this Proton-GE fork works great and now I don't have the FFB problems described on previous messages. Also works great on Pista Motorsport.

It would be great to fix the stuttering problems that make this title unplayable, although I don't know if it's due to Wine/Proton, or the game itself. I've tried the trick of setting the Texture Size Pool to Ultra, but it works sometimes, sometimes not. It also often happens that it gets stuck on the loading screen and you have to kill the process to exit.

I am still having a lot of problems. Since the last patch 0.1.4 I can't fix the stuttering if I set the Texture Size Pool to Ultra (with the past version worked). Now the game stalls always when loading the race, and only responds if I delete the prefix and regenerate it, but when I close the game and reload it, the same thing happens again, as if something is corrupted in the prefix. I don't know if it happens to any of you?

@leillo1975 I had this, but I'm not sure it was with 0.1.3 or 0.1.4

And you don't need to delete all prefix, try to remove video settings file video.videosettings from <..>/SteamLibrary/steamapps/compatdata/3058630/pfx/drive_c/users/steamuser/Documents/ACE

Thanks, I'll check it out as soon as I get home, and then I'll let you know how it went. Were you able to correct the stuttering?

@leillo1975 I had this, but I'm not sure it was with 0.1.3 or 0.1.4

And you don't need to delete all prefix, try to remove video settings file video.videosettings from <..>/SteamLibrary/steamapps/compatdata/3058630/pfx/drive_c/users/steamuser/Documents/ACE

Your workaround is good! I created a backup of a working config and when I get a hang , I restore it and then the game works again. I also test the last bleeding-edge proton Experimental, and now I have no stuttering (I didn't tried with other Texture Size Pool setting than Ultra). The only problem is that I can't use the @JacKeTUs proton-ge mod to avoid FFB problems

I also test the last bleeding-edge proton Experimental, and now I have no stuttering

I can confirm. Still few really tiny stutters per LAP. But is totally drivable.
Texture Size Pool setting was Height

https://github.com/user-attachments/assets/4b88bb50-87c1-437c-a4b4-c7686e256c3d

Any information about this issue?

Happens with all the Proton versions I could try.

Hi again. I found that with nvidia 570 Beta graphics drivers, the stuttering is gone!

Assetto.Corsa.EVO.-.2025-02-04.10-59-08.AM.mp4

Any information about this issue?

Happens with all the Proton versions I could try.

The latest Proton Experimental fixed this problem!

Running on a RX 9070, Arch Linux, kernel 6.14, mesa 25.0.3, I think there was some kind of regression in Proton Experimental, this happens sometimes while on track and almost everytime returning to menu, and when it happens I have to restart the game to fix it. Regular Proton 9 doesn't have this issue but has this https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2633418883.
EDIT: Actually, it's the same on Proton 9, maybe it has something to with the card being too new, but I'm not sure. I was using a 6700xt until 2 weeks ago and it was fine.

Running on a RX 9070, Arch Linux, kernel 6.14, mesa 25.0.3, I think there was some kind of regression in Proton Experimental, this happens sometimes while on track and almost everytime returning to menu, and when it happens I have to restart the game to fix it. Regular Proton 9 doesn't have this issue but has this [#8395 (comment)](https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2633418883). EDIT: Actually, it's the same on Proton 9, maybe it has something to with the card being too new, but I'm not sure. I was using a 6700xt until 2 weeks ago and it was fine.

rx 6700 xt here , at some earlier version of AC EVO I had the exact same corruptions , but they came gradually after each race / car swap , since then changed graphic settings much , and had no longer seen this.
Maybe some settings where resetted when inserting the new card ? (maybe some pool issue / epic setting that increases the odds of that happening?)

Replying to https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2781675047

It was the "texture pool size" being set to ultra, I put it back to high and it seems to have solved the problem, thank you! I probably had already tried to lower this setting but I read people reporting that it doesn't apply it until the game gets restarted.

I noticed that changing wheel settings (gain, damper, etc..) in game is ineffective. Does anyone else have this problem?
I use a Thrustmaster T300RS GT with https://github.com/Kimplul/hid-tmff2
Changing settings with Oversteer works, and also passing options directly to the driver is working, but not the game settings.

I noticed that changing wheel settings (gain, damper, etc..) in game is ineffective. Does anyone else have this problem? I use a Thrustmaster T300RS GT with https://github.com/Kimplul/hid-tmff2 Changing settings with Oversteer works, and also passing options directly to the driver is working, but not the game settings.

I am pretty sure this only adjust the INGAME gain / damper settings, your wheelbase settings are not controlled by the game.

Most wheel bases have their separate damper / spring settings , and something like a "master" GAIN setting to limit the force independent of the games FFB signal.

https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2849136171

So after a bit more tests, I came to the conclusion (wrong or right I don't know) that it must be regression in Proton 10.
Basically, it looks like whatever settings I load Oversteer with, it doesn't pass those to the game if it's set to Proton Experimental (experimental is based on 10 now as far as I know). The wheel springs back to center as soon as I start the game, like if it's resetting, feels like no ffb effect works apart from basic centering.
Setting compatibility back to Proton 9 works as always, all effects work (what the driver exposes) and I can tune effects in game.
It must be Proton 10 because nothing else changed recently, neither the game, wheel drivers or Oversteer.
EDIT: Attached proton log
steam-3058630.tar.gz

@Mattyan1989 Could you give some more details on how you setup "Oversteer"? I'm not familiar with that ... also - could you please get another log using this launch option to help us diagnose this better?
And What wheel are you using? PROTON_LOG=+hid,+hidp,+hid_report,+plugplay,+rawinput,+dinput,+xinput,+joystick,+setupapi,+input %command%

@alasky17 Thank you, so my wheel is a Thrustmaster T300RS GT Edition, I'm using this driver https://github.com/Kimplul/hid-tmff2 and Oversteer https://github.com/berarma/oversteer I usually launch Oversteer, load a profile with a default setting for my wheel and leave it open in the background while I launch the game. I always used Proton Experimental, everything worked while it was based on Proton 9, when it switched to 10 the problem started.
Now when I start the game it seems to disregard whatever I set it to, the wheel becomes very stiff (and it strongly springs to the center if I leave it uncentered); when on track all ffb effect are missing apart from the strong centering and in game settings have no effect. I tried not using Oversteer, but it's the same; whatever default settings are coming from the driver, they seem to be ignored.
I registered logs of the game starting both on the old Proton Experimental 9 and the current one, using the suggested launch options, with the wheel connected and oversteer in background.
exp9.log
exp10.log

@Mattyan1989 Can confirm autocenter issue but I can fix it by changing "Autocenter strength" in Oversteer to anything but 0 and back to zero. Looks like starting Proton 10 sets it to max value on start?

I also still have the issue where the FFB just cuts off, but maybe Proton is just based on and old Wine version/without fixes?

@Pengukov Your workaround works, it was the autocenter all along. Proton definitely messes up with this so it would be great to have it fixed.

I still have the ffb cutting too. It was reportedly fixed in Wine with this patch: https://gitlab.winehq.org/wine/wine/-/merge_requests/7217, merged into master on Jan 28th. Wine 10.0 released on Jan 21st and Wine 10.1 released on Feb 7th. So if Proton is based on Wine 10.0 it's probably not included. @alasky17 Could this be checked too and possibly have the patch imported into Proton?

I still have the ffb cutting too.

This should be fixed in game, game should not send values over the documented range.
I know somebody already sent bug report about this, but it seems developers didn't fix this.

You can use my old build of GE-Proton-9.23 (https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton9-23-FFB) which has this patch.

@JacKeTUs It works but it has this graphical glitch, which was fixed on one of the final updates of the Proton 9 Experimental
Also, I too sent a bug report to the devs a week ago or so, let's hope it makes into a future patch.

@Mattyan1989 may be you know if latest GE-Proton also fixed this artifact glitch? I can't test this rn, but i can update my fork

@JacKeTUs Yes, it's fixed for me on the latest release (9-27)

Can you please try updated build?
https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton9-27-FFB

Seems to work from a quick try, thank you!

Can you please try updated build? https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton9-27-FFB

Hey, I just wanted to thank you for this. This fixed the FFB micro cutting!

I personally still have the problem where the FFB auto centers when I start the game. I fix it going to Oversteer and putting the autocenter strength (and damping) at zero. But previously I didn't need to use Oversteer for anything. How odd.

still have the problem where the FFB auto centers when I start the game

I wonder if it's linked to our patches to pidff... What wheel are you using? Also, can you log FFB commands with ffbwrap from https://github.com/berarma/ffbtools, to see if it's the game who sends out Spring effect?

still have the problem where the FFB auto centers when I start the game

I wonder if it's linked to our patches to pidff... What wheel are you using? Also, can you log FFB commands with ffbwrap from https://github.com/berarma/ffbtools, to see if it's the game who sends out Spring effect?

I have a G27. I tried with Proton 9.0-4 and the autocenter issue is not there (but the gfx artifacts are).

I've installed ffbtools from the AUR, but I don't know how to use it...

I tried on my T300 without using Oversteer and with this launch option:
/home/xxxxx/ffbtools/bin/ffbwrap --logger=/home/xxxxx/log --throttling --throttling-time 19 /dev/input/by-id/usb-Thrustmaster_Thrustmaster_T300RS_Racing_wheel-event-joystick -- %command%
both on stock Proton 9.0-4 and current experimental:
experimental.log
proton9.log

It looks like autocenter effect is now available from Proton, and game sends this into the device (probably for autocenter the wheel in menu? May be it disables autocentering when in race?)
Does the autocentering with newest Proton occuring in other games, or only in AC EVO?

No it isn't disabled when on track.
This is the log for AC Competizione on Experimental:
expACC.log
Strangely it looks like it does the opposite here: wheel gets lighter on game boot, there is a light autocenter while in game gain is set to 100%, and almost disappears when lowering this setting. When closing the game, the wheel strongly springs to its center position.
EDIT: These two latest tests with experimental had bleeding edge enabled

Does the autocentering with newest Proton occuring in other games, or only in AC EVO?

I also have Mudrunner installed and the autocenter activates the moment the game starts. So it looks like it's a Proton problem.

@Pengukov Your workaround works, it was the autocenter all along. Proton definitely messes up with this so it would be great to have it fixed.

I still have the ffb cutting too. It was reportedly fixed in Wine with this patch: https://gitlab.winehq.org/wine/wine/-/merge_requests/7217, merged into master on Jan 28th. Wine 10.0 released on Jan 21st and Wine 10.1 released on Feb 7th. So if Proton is based on Wine 10.0 it's probably not included. @alasky17 Could this be checked too and possibly have the patch imported into Proton?

We cherry-picked this and it is now live in experimental-bleeding-edge (which must be selected as a beta branch in the experimental tool itself). It will also be in the next regular experimental release. @Pengukov @Mattyan1989 It would be great to get some feedback (haha) on whether or not this helps with the Force Feedback because it is difficult for us to test. We also are looking into the autocenter issue :)

@alasky17 Thank you, bleeding edge now fixes the FFB cutting in my setup!

@alasky17 could only to a quick check (on 0.2) for now but same as @Mattyan1989, seemed to work fine
Newest ACE patch (0.2.1) also has this in patch notes:

• fixed out of range values sent to the Force Feedback

The latest game update fixes the out of range values problem!

Now only the autocenter issue remains.

Can confirm FFB doesn't cut anymore with newest ACE patch (guess for testing if Proton behaves like Windows another games need to be tested, e.g. PISTA Motorsport).

@JacKeTUs
As for the autocenter I tested some games.
Quick notes: I use Sway window manager so behavior might change with others and when I say "selected" I mean "activating" the window (whether they were visible before selecting didn't matter) by mousing over it (no need for clicking in Sway) or switching workplaces/active windows by keyboard.

Assetto Corsa EVO: autocenter when starting, fixable by Oversteer "trick", goes back to 100% when quitting game, selecting Steam/AntiMicroX does NOT change anything (either from game or directly after Oversteer change).

Assetto Corsa Competizione: no autocenter until closing the game (except when standing still, assuming through game since it is weaker).

Automobilista 2: initial autocenter seems to be overwritten by "Menu Spring Strength" from ingame FFB settings.
When manually setting Autocenter strength to 100% in Oversteer it is also strong in menu when switching back to AMS2, unless Steam is selected first after setting it to 100% in Oversteer and then switching to AMS2 in which case it's gone (overwritten by game I guess).
When tabbing from the game into Steam or AntiMicroX (but not other windows), autocenter effect returns until switching back to game.
Also when doing the Oversteer fix, selecting Steam has no effect, but selecting the game and then Steam the autocenter returns.

Euro Truck Simulator 2: autocenter active and autocenter returns to full strength (after Overstreer trick) when selecting the game or when selecting Steam/AntiMicroX after changing it in Oversteer.

Not having AntiMicroX started didn't seem to change anything.
Tests were done with the Proton 10.0-1 beta.

after the latest update thrustmaster t300rs not working anymore. my moza pedals works, steering detected in game but no input or axis working anymore

@fuzunspm Still works for me (on Proton 10.0-1 beta). If it works in other games I would just rename (or delete if backup is not needed) the proton prefix (../Steam/steamapps/compdata/3058630/) to create a new prefix.

@Pengukov thank you very much, it fixed the issue, It's basic but effective fix for potentially every other game. Awesome!

@Pengukov Does your peripheral input device break if you downgrade to Proton 9 and upgrade to Proton 10? (without deleting the prefix) ... generally, if something consistently requires a fresh prefix to work when switching between Proton versions (up or down), we'd like to look into it as a potential regression since we strive to be backwards compatible between Proton versions :)

@alasky17 can bug with autocenter hide somewhere there?
https://github.com/ValveSoftware/wine/blob/e4edc49abf0a48b628bb5291b1bbe4c82af5c2cf/dlls/dinput/device.c#L2149
Every time dinput device is initialized, autocenter is set to ON, and it's only changing when new prop is set (https://github.com/ValveSoftware/wine/blob/e4edc49abf0a48b628bb5291b1bbe4c82af5c2cf/dlls/dinput/device.c#L1310). Author of the original patch for enabling autocenter (https://gitlab.winehq.org/wine/wine/-/merge_requests/4830) claims:

dinput acquire does (1) a reset (this enabled autocenter) and, if autocenter is disabled, (2) a stop all effects (this disabled autocenter).

But when using Proton, Wine initializes devices every time game is starting, and autocenter is set to ON by default, so no 'stop all effects' occuring right after DC_DEVICE_RESET.

Sadly i don't see any way to simply get autocenter status from the device right now 😢
It looks like it needs patches to the multiple targets (SDL, linux joystick drivers) for acquiring this information.

May be you can (for now) set autocenter to ON only when, say, env var PROTON_JOYSTICK_AUTOCENTER is 1, and keep it disabled by default? Or another way, disable autocenter with PROTON_JOYSTICK_AUTOCENTER=0 and keep it enabled by default as in upstream

Follow up: I tried to add this idea to Proton GE. Autocenter is disabled by default, but it can be enabled with PROTON_ENABLE_AUTOCENTER=1
@Pengukov, @Mattyan1989, for autocentering issue, can you try this build? I don't have device with autocenter effect exposed, so i can't test this properly myself, but it should just work

https://github.com/JacKeTUs/proton-ge-custom/releases/tag/joystick-disable-autocenter-1

If it works, may be we can consider disabling autocenter by default with upstream Wine... And only after some form of 'get_autocenter_status' implemented in SDL and kernel, we can turn it back and actually initialize device with current settings.

Also, added ignore-autocenter option to ffbwrap: https://github.com/berarma/ffbtools/pull/47

@JacKeTUs Following up as well :). - thank you for pointing to that commit. We tried reverting it and also confirmed it is the single commit making the autocenter behavior change in our testing. Your suggestion for a gate is greatly appreciated and we'll hopefully decide on some course of action soon -- this is why 10 is still in "beta" :D

https://github.com/JacKeTUs/proton-ge-custom/releases/tag/joystick-disable-autocenter-1

@JacKeTUs @alasky17 I did a quick test and it seems to work fine.

@JacKeTUs
So I tested the games I tested before:
AC EVO + Competizione: No autocenter when starting but when closing the game
AMS2: same as ACE but also does not return when selecting Steam
ETS2: same as ACE but tabbing out of game brings back autocenter until game is selected again
When autocenter is active due to closing a game, starting a game deactivates it (steering axis might need to be assigned, at least in ETS2)
[Edit] Just to clarify: in Windows there is an autocenter effect (unless the wheel settings are open) which is active after closing the game. But the ETS2 behavior is not present (no autocenter when alt-tabbing)

@alasky17
Ok, so I never had an issue with that switching Proton versions as far as I can remember and also did a test for AC EVO going from 9.0-4 to 10.0-1 to 8.0-5 (didn't start) back to 10 and they were always detected.

What I have an issue with since I tried simracing on Linux is that when restarting my PC, input devices were not detected properly. Sometimes I had a device twice (but only one working), sometimes it wasn't listed or it was listed but didn't work, the wheel input was detected as pedal input and stuff like that.
To fix this I had to create a new prefix, so that was my first idea.

Yesterday I confirmed that it still happens, on my Arch install and also freshly installed hid-tmff2/hid-fanatec/oversteer on openSUSE.
There were also some problems with the SDL3 update shortly but otherwise nothing changed.
This does not happen in every game but most. Euro Truck Simulator 2 (via Proton, but does have a native port) seems fine as does BeamNG.drive native and via Proton.

Since I know enough to cause problems I just looked into how/where Linux has the inputs, and since the games seemed to be confused about where the device is and the event IDs changed with reboots, I renamed/relinked all the inputs via script.
Basically I did this for every simracing device:

mv "$(realpath /dev/input/by-id/usb-FANATEC_FANATEC_CSL_Elite_Pedals_LC-event-if00)" /dev/input/event702
for link in /dev/input/by-path/*; do
if [[ $(realpath "$link") == $(realpath "/dev/input/by-id/usb-FANATEC_FANATEC_CSL_Elite_Pedals_LC-event-if00") ]]; then
rm "$link"
ln -s "/dev/input/event702" "$link"
fi
done
rm "/dev/input/by-id/usb-FANATEC_FANATEC_CSL_Elite_Pedals_LC-event-if00"
ln -s /dev/input/event702 "/dev/input/by-id/usb-FANATEC_FANATEC_CSL_Elite_Pedals_LC-event-if00"

What I didn't touch was the steering wheel ("Thrustmaster T300RS") because that broke FFB and it worked due to using Oversteer anyway. All the other devices (pedals, h-shifter, handbrake) would randomly have problems (they still work in evtest, just not ingame).

Since no other device seemed to have this issue and I could find absolutely nothing about it online, the problem was solved once and for all. Well, I just didn't get around to try to figure out what even is the problem since I had other USB issues as well but didn't know if they are related (Rift CV1 sensors broke the USB bus on Manjaro and I had to block them, wireless receiver broke booting on Arch when mouse was connected via cable, sometimes booth mice stop working one after another, random stuff like that).
I also do connect the entire wheelstand via a USB hub (5-6 devices), which might affect things.
Always meant to check with the Linux SimRacing community since I could not find anyone else with that problem.

So yeah, since I had to delete a lot of prefix while testing this...always my first approch. I'm guessing the device link info is stored somewhere in there?

@Mattyan1989 @JacKeTUs and anyone else using oversteer - a fix just got pushed to experimental-bleeding-edge that we hope will improve oversteer behavior on Proton 10. You will need to find the Proton - Experimental tool in your Steam library and select the "bleeding-edge" beta branch in properties to get the correct build. Please let me know if there is any unexpected behavior still happening with oversteer. We did not just revert the original fix - hopefully this is an improvement :)

Edit: for any curious, the commit is: https://github.com/ValveSoftware/wine/commit/86198bcd5ad4dc9800801ff5c5320d3041549fd8

@alasky17 It does seem to work as expected with AC EVO/Competizione (no autocenter efffect at all, Oversteer also doesn't behave like the Thrustmaster settings in Windows i.e. there is no autocenter in Linux when closing the app but there is in Windows).
But that version breaks my mouse in Euro Truck Simulator 2 (can't move cursor) and Automobilista 2 has some trouble starting for me, but there seemed to also be no autocenter.

@Pengukov Hmmm ok - if it would be ideal to match Windows better, it would be helpful to write out detailed steps of what you are doing, what settings you have, and then what you expect to see on Windows vs what is happening now. But at least not being more broken than 9.0 is nice :)

WRT "that version breaks my mouse" - are you talking about Proton - Experimental? Compared to what working Proton version? Especially if this is a regression, feel free to move the report to https://github.com/ValveSoftware/Proton/issues/5049 and tag me :)

@alasky17 So I realized that the autocenter value actually should not be overwritten and instead be kept (like Proton 9.0-4 does), since current behavior is not consistent with how Windows works (at least with the Thrustmaster software). Sometimes the user might want to have an autocenter effect (e.g. when a game does not support any force feedback).

With the current bleeding edge implementation when I set say 30% autocenter, it gets disabled when starting a game. I can then set it again in Oversteer to make it work again in some games, but not all.
In Automobilista 2 for example the Oversteer autocenter effect always disappears when I switch back to the game from setting it in Oversteer. How it actually should behave is adding booth autocenter effects, like 30% Oversteer and 40% ingame will be just 70% instead either alone (it does so in 9.0-4 and Windows).
So something in Proton 10 changes the autocenter/FFB while 9.0-4 did not.

In Windows when I set 30% autocenter "by-the-wheel" it just keeps it when starting a game.

When selected "by-the-game" it will have autocenter in Windows when no game is started (as much as is set), but this is OS userspace anyway and should be handled by Oversteer/driver. That's why I had autocenter in Windows but not Linux, but Proton should not change anything from what is set by the system anyway, but I don't know how Proton/Oversteer/drivers interact with regard to setting/saving values and stuff.

A disconnect here also comes from the fact that the Thrustmaster software has the "by the game" and "by the wheel" as option how autocenter behaves. Oversteer does not have this options and basically works as "by the wheel".
Since Oversteer is not only for Thrustmaster I don't know what the behavior overall is.
Regarding this there is an open issue for Oversteer:
https://github.com/berarma/oversteer/issues/262
I'll make a comment and link here, maybe someone has more info/input (speaking of, this isn't really a AC EVO issue but more genral FFB input related, not sure if it should continued elsewhere?).

Also regarding how Oversteer handles autocenter:
https://github.com/berarma/oversteer?tab=readme-ov-file#known-issues
Known issues
Most drivers don't support Global Gain and Autocenter settings, only new-lg4ff for now. The Linux API is used instead when they aren't available. If this happens, Oversteer has to reset their values everytime it starts. Also, games will be able to override these settings.

Not sure if Assetto Corsa EVO is the right place to discuss autocenter feature itself for proton, even more what oversteer has in relation with that (as is only a GUI configurator) but to clarify:

• thrusmaster driver has a config for autocenter using wheel: https://github.com/berarma/oversteer/pull/268#issuecomment-2932267237

Hold Mode button and press left or right arrow. Red light will flash 3 times for 540, 4 times for 7xx, 5 times for 1080. Have in mind you have to do this after every race starts, even if you retry. It resets back to 1080.

• thrustmaster driver has a switch to check if setting by wheel is honored or setting by software ("game") is

• oversteer only configure setting by software at this moment

You can enable the switch with:

echo y | sudo tee $(sudo find /sys -name enable_autocenter)

or disable with "echo n" ...

@Mattyan1989 @JacKeTUs @Pengukov More changes have been pushed to the experimental-bleeding-edge branch (You need to select bleeding-edge beta from within the Proton - Experimental tool to select this version). We are still investigating, but so far it looks like (at least with some wheels) on Windows, some games do reset things that were set by the user every time the game is launched :/. @Pengukov Thank you for the comment earlier ... this is incredibly complicated because the behavior seems to differ by game and possibly wheel too :/

So like @alasky17 said the bleeding-edge branch now supports an experimental WINEBUSCONFIG environment variable (and Wine registry keys) to allow control over how we handle autocenter:

The environment variable can be set with a pattern of vid/pid=<config>,vid=<config>,vid/pid=<config>,... where vid and pid are 1 to 4 hexadecimal digits of the device vid/pid (product id is optional and vid=<config> applies to every device matching this vendor id).

Each <config> can then be a sequence of / separated hidraw, nohidraw, autocenter, noautocenter tokens, or autocenter:<on>-<off> where <on>/<off> are the numeric value to use for the autocenter gain (in the 0 to 65535 range) when it is enabled/disabled by applications. The noautocenter config should prevent any modification of the autocenter value and leave it unchanged by Proton. Using autocenter without any value should be the same as the current Proton - Experimental setting, where we enable / disable autocenter, but try to read the value that may have been previously set by external applications.

For instance this could be: WINEBUSCONFIG=054C=hidraw,3344/412f=autocenter:65535-0,0eb7=noautocenter/nohidraw

The same configuration can also be set in the Wine registry, although that may be a bit more complicated to edit under Proton, under the HKLM\\System\\CurrentControlSet\\Services\\WineBus\\Devices key, with <vid>/<pid> or <vid> subkeys. Each device subkey can have an "Hidraw" DWORD value set to 0/1, and an "Autocenter" STRZ value set to "enabled", "disabled", or "<on>-<off>". For instance, for the same config as above a registry file could contain:

[System\\CurrentControlSet\\Services\\WineBus\\Devices\\054C]
"Hidraw"=dword:00000001

[System\\CurrentControlSet\\Services\\WineBus\\Devices\\3344/412f]
"Autocenter"="65535-0"

[System\\CurrentControlSet\\Services\\WineBus\\Devices\\0eb7]
"Autocenter"="disabled"
"Hidraw"=dword:00000000

Please let me know if this doesn't work as intended, also I'm considering adding this to Wine as well, so let me know if there's anything we can improve about it.

On Proton bleeding-edge, I was able to replicate the "by the wheel" Thrustmaster Windows setting behavior for a T248 with the launch option WINEBUSCONFIG=044f=noautocenter/hidraw %command%. Be sure to replace 044f with your wheel's vendor ID, which can be found by running lsusb -v.

Finally got around doing some basic testing (Thrustmaster T300RS, Automobilista 2/Assetto Corsa EVO).

Without options or "WINEBUSCONFIG=044f=autocenter/nohidraw %command%":
Basically "by-the-game" option, Oversteer autocenter is deactivated when game starts but does not reactivate when exiting game (Windows with Thrustmaster software to "by-the-game" would reactivate autocenter when exiting game)

WINEBUSCONFIG=044f=noautocenter/nohidraw %command%:
AMS2 is like Windows "by-the-wheel" (like "codeweaverwill" mentioned): Oversteer and ingame menu autocenter effects add up, exiting game only Oversteer effect active. ACE has no autocenter so just Oversteer active.

Had no problems with "alt-tabbing" but did not test extensively.

As for the return of autocenter, this might be useful to prevent damage with powerful wheels left at a random position when suddenly an effect starts. But at least it is not necessary for the games itself (and I don't know how other software handles this on Windows anyway).

Also thanks for all the work from everyone! :)

@rbernon hmm, couldn't the fix be easier and more straightforward? Currently, linux' ff api doesn't expose device control at all and most games send out reset when starting. Currently, if something sends DC reset, the only thing done is to set device gain to max. Why not disable autocenter as well?

And well, plumbing device control, exposing axes and a way to query for effects and states is something I'm working on.

I think this is the case where doing everything exactly like Windows is not a great idea as we don't have access to all the necessary FF bits. And the first assumption of autocenter being just a spring effect on slot 1, yeah, that was MAYBE true for MS Sidewinder joystick from over 20 years ago. The USB PID standard doesn't describe any explicit autocenter method and the Windows implementation is just based around the MS Sidewinder joystick.

That autocenter thing is not coming from dinput but from the USB PID driver and should be left to the drivers as well. I myself just done effect-based autocenter for the Linux PID driver which explicityl uses spring + friction but we're still debating if that's something we'd like turned on at device init.

Of course, the issue with Wine is that it actually suports PID directly for the virtual devices and I don't know if there's a way do distinguish between a hid/SDL device and hidraw device but at least for non-hidraw, autocenter should be left alone (IMO).

Reset should absolutely not enable autocenter in this case. Reset is simply a shorthand for continue, enable actuators, stop all effects and clear all effects. Weirdly enough, dinput calls for actuators off but this is then contradicted by the Windws' USB PID driver which doesn't sent out reset + actuators off, only reset when dinput reset is called. Still, it should be left in it's startup state and if it can't detect autocenter properly (which can't be done on linux as ff-api lacks querying) it shouldn't set it.

I think that's where the dinput/USB PID driver thing in windows gets murky and the autocenter thing is just a hack on top of PID standard, not supported by 99%+ of hw.

https://gitlab.winehq.org/wine/wine/-/merge_requests/8605

For those of you with force feedback devices, I would be very grateful if you could run a small program I put together to report on the state of autocentering for you device and report the results back to me.

Please also tell any of others that you may know who have other devices to do the same too.

Thanks very much in advance!

I'm back on the game after some time and I noticed that the ingame "damper gain" (for wheel behaviour while the car is stopped, as the game explains it) works different than Windows: on 0% the wheel offers no resistance at all (same as on Windows), on 100% it autocenters like the car is moving, while it should stop at the point where the user turns it, offering some resistance to the steering and thus simulating the stopped car properly. On Windows it works as intended. (Thrustmaster T300GT)

@Mattyan89 Could you please say which Proton version you are seeing that behavior on? And could you please test Proton - Experimental and Proton 9, and see if you get the same behavior or if the behavior on Proton 9 is better/worse?

Proton 10.0-beta would be bonus if you like comparing things for fun :)

@alasky17 Sorry, I should have mentioned that it was on experimental. 9 and 10.0-beta behave the same.
EDIT: In Automobilista 2 damping works fine
EDIT2: ffbwrap logs with 0 and 100 damper gain, entering a session and turning wheel from side to side while stopped
0_damper.log
100_damper.log

Hi there.
I tried AC Evo and I wonder why the game performance is so terrible. Indeed, I can run ACC without any issue (not high-end PC, GTX970, 16GB RAM ) but it runs smooth at 60FPS. AC Evo runs really bad with low res, ultra low graphics, and runs at best at 23 FPS (ingame).
I admit this is not the same game engine, but it is really un-playable. Do you know if there any quirks or issues with the perf?

In my understanding, bad performance is related to https://forums.developer.nvidia.com/t/directx12-performance-is-terrible-on-linux/303207

@cazzoo the new kunos engine still needs a lot of optimizations and is currently heavier than ACC. Your GPU is now almost 12 years old. It's bound to happen.

While I agree my machine is far from being top-end one, it decently run most of the recent games (in medium or low) with a reasonable resolution (most if not all recent racing titles, but ACC).
I appreciate Kunos is bringing a new engine that is probably not optimized yet, so I will consider the situation to improve over time.
I believe the performance issue I probably related to the memory issue shared by dinuxit. It seems Nvidia is aware and would provide soon (TM) some improvements in that regard.

Let's keep in touch

I hadn’t run it for months, and now it doesn’t work; I’ve tried it with Proton 10, 11 and the CachyOS version. The game shows the icon in the toolbar but nothing happens.

steam-3058630.log