Same behaviour since the changes made after proton 6.3-8 with further bug tracking
#5869

have exactly same problem under linux with my G29 and dual thrustmaster Farmstick joysticks, right x-axis and up y-axis works but left and down is dead and machine in game loops around when turning left. Farming Sim 22 works fine with proton 6.3-8 still but Farming Sim 25 wont start with this version of proton

Digging a bit further. The game developer changed the behavior of their game engine some time ago. Farming simulator 17 used XInput for Xbox Gamepads und DirectInput for any other device. Since Farming Simulator 19 XInput for Xbox Gamepads and Windows Raw Input for all other devices. If I understand this design decision correctly it enables them to implement own device support independent from the hardware developer. You can therefor map the buttons and change the device behavior by changing the corresponding xml file in
/steamapps/compatdata/2300320/pfx/drive_c/users/steamuser/Documents/My\ Games/FarmingSimulator2025/inputDevices/

e.g.
<deviceMapping backends="rawInput;directInput;macosXSdl"> <productKey productId="C262" vendorId="046D" /> <productName vendorId="046D"> <keyword text="g920" /> </productName> <category>wheel</category> <!-- gamepad, wheel, joystick, farmWheel, farmSidePanel --> <buttonMappings> <buttonMapping physical="0" logical="1" label="A" /> <buttonMapping physical="1" logical="2" label="B" />

In Farming Simulator 22 #5351 you could use your wheel until the underlying version of wine succeeded 6.3-8
Using the game developer console you can see that many buttons are detected, but the main features of the wheel

• 0 RX (steering)
• 10 ACC (accelerate)
• 11 BRK (brake)
• 12 CLT (clutch)
  
  are missing, but are fully working in game.

What changed after wine version 6.3-8? There had been a huge rework done by @rbernon and other at codeweavers to make a better use of the way wine processes the input. My guess is that those two commits:
Commit f9d7acbf winejoystick.drv: Remove unnecessary driver.
Commit 4f1095a0 winmm: Reimplement joystick APIs on top of dinput.
kind of "broke" the detection/use of the wheels by the developers game engine.
Documentation of changes using the new input processing by wine

Coming back to the actual situation of Farming Simulator 25.
The game detects the logitech device including

• 0 RX (steering)
• 10 ACC (accelerate)
• 11 BRK (brake)
• 12 CLT (clutch)
  
  If you steer a bit to the left (RX), then the game immediately detects the value 1.0 which equals to a full steer to the right. Center is 0. Steering to the right works incrementing values from 0 to 1.0.
  Using the pedals shows the same problem the value is set to 1.0 when not activated. When you press the ACC pedal the value increases from 0 slowly:

until you reach exact 50% Acceleration. Pressing the pedal further down it's keeping the full 1.0 value

I'm no developer. My guess is that you could revert those two commits and compile a recent proton version just for this game, but without real proper usability (force feedback, in game options, etc).
There seems to be a bug how the input values are read (or made available by wine) by the Giants Software game engine.
I don't have to much confidence in support from the developer (their Windows version works) -> it's a wine/proton problem.

Maybe someone with more knowledge could debug this further.

I have the same issue with the newer version of the Logitech G29 (PC, PS4, PS5) despite axial input being correctly recognised by the OS. When opening FS25 with Proton 6.3-8 in "PC" mode, wheel and pedal movements are accurately displayed in the options menu, but it won't load into a map, of course.

I am also having the same issue with the USB Thrustmasters. Tried Proton 6.2, which kept asking to wait or close, up to Beta 10.

Same issue with Logitech G29

This isn't a problem with Proton/Wine but how the game handles input.

By the way, Mechwarrior 5 has the same issue with joysticks/hotas.
https://github.com/ValveSoftware/Proton/issues/5869
https://www.protondb.com/app/2000890?device=pc
FYI, fs25 engine - Giants engine, mechwarrior - ue4.

Just additional info, may be will help someone to investigate.

I got it to work by setting PROTON_ENABLE_HIDRAW=1 in the launch options. Mightve done other stuff too that I dont remember and not sure if they were significant. But this option for sure made it work, and removing it I get the same behavior as before (turning to the right works but any left movement results in a full right input).

Using a logitech g923 and farmstick on latest Proton version.

Edit:
Also have the following udev rules:
/etc/udev/rules.d/40-usb_modeswitch.rules

#Logitech G923 Racing Wheel (Xbox Mode)
ATTR{idVendor}=="046d", ATTR{idProduct}=="c26d", RUN+="usb_modeswitch '%b/%k'"

This puts the G923 into Xbox mode.

/etc/udev/rules.d/60-hidraw-farmstick.rules

# Farmstick
KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="0416", MODE="0660", GROUP="plugdev"

# G923
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c26e", MODE="0660", GROUP="plugdev"

For this one make sure your user is in the plugdev group (which should already exist; if not, create it).

Restart your computer after adding these files.

For G923 I also installed https://github.com/berarma/new-lg4ff for the driver, although force feedback still doesn't work for me.

I got it work as well for my Logitech G29

1. Launch options: PROTON_ENABLE_HIDRAW=0x046d/0xc24f %command%
2. Created /etc/udev/rules.d/60-steam-input.rules with:
   KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c24f", MODE="0660", TAG+="uaccess"
3. restart pc
4. (not sure if this needed, i've done it before the game start. Check without this step first) remove any section from system.reg in compdata folder of the game with text vid_046d&pid_c24f
5. start the game

Checked on GE-proton 10-3 & GE-proton 10-10
046d & c24f this is vendor & product id of logitech g29

1. Created /etc/udev/rules.d/60-steam-input.rules with:
   KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c24f", MODE="0660", TAG+="uaccess"

Thanks for reminding me about udev. I updated my above comment with my files. It's hard to remember everything you did when you spent hours trying a hundred things to get it working ;)

Replying to https://github.com/ValveSoftware/Proton/issues/8671#issuecomment-3124315887

This definitely works when using only a G29. How would one add multiple devices? For example the Logitech 3D Pro also has messed up axis

Same type of crash as before, here is the proton log: https://gist.github.com/eniac1986/0eb8a0f79dea8954aeb1178ae8c10c43

Replying to https://github.com/ValveSoftware/Proton/issues/8671#issuecomment-3168488184

@RogueRaiden see my post above where I am using G923 and Farmstick and have both working.

When I was looking at the code for PROTON_ENABLE_HIDRAW I concluded that it can't have more than one device listed (e.g., by using commas). This matched my own experiences too trying PROTON_ENABLE_HIDRAW=0x046d/0xc26e,0x44f/0x0416 which I only tried since I saw some others online also try it.

Here is the code that processes that option from https://github.com/ValveSoftware/wine/blob/3e255b997c306b83745193775bc8e1ef96a00ca7/dlls/winebus.sys/main.c#L478-L484:

    if (!RtlQueryEnvironmentVariable(NULL, L"PROTON_ENABLE_HIDRAW", 20, value, ARRAY_SIZE(value) - 1, &len))
    {
        value[len] = 0;
        if (!wcscmp(value, L"1")) return TRUE;
        swprintf(vidpid, ARRAY_SIZE(vidpid), L"0x%04X/0x%04X", vid, pid);
        if (wcscasestr(value, vidpid)) return TRUE;
    }

So if you set PROTON_ENABLE_HIDRAW=1 it enables it for all devices which should make it work.

You also need to make sure you have udev rules set up for both devices to enable hidraw.

Replying to https://github.com/ValveSoftware/Proton/issues/8671#issuecomment-3168488184

just change 046d & c24f with your vendor & product id of your device (lsusb can help to find). For several devices just add one more line with ( KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c24f", MODE="0660", TAG+="uaccess" ) with new vendor & product id of your next device, and add new vendor & product id to the PROTON_ENABLE_HIDRAW launch option. Separate devices in PROTON_ENABLE_HIDRAW by comma.

@kjsmita6 @Ekzilit
Thanks guys. I was missing the comma or 1 value for PROTON_ENABLE_HIDRAW. After some frustration with the udev files not loading or whatever it was, it all works now.

Just for example my launch options for fs25: PROTON_ENABLE_HIDRAW=0x046d/0xc24f,0x06a3/0x0762,0x06a3/0x0c2d,0x044f/0xb10a,0x044f/0xb687,0x044f/0xb660 %command%

rules

# Logitech G29 wheel
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c24f", MODE="0660", TAG+="uaccess"
# Saitek x52 pro
KERNEL=="hidraw*", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0762", MODE="0660", TAG+="uaccess"
# Saitek Quadrant
KERNEL=="hidraw*", ATTRS{idVendor}=="06a3", ATTRS{idProduct}=="0c2d", MODE="0660", TAG+="uaccess"
# Thrustmaster T.16000M Joystick
KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b10a", MODE="0660", TAG+="uaccess"
# Thrustmaster Throttle
KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b687", MODE="0660", TAG+="uaccess"
# Thrustmaster T500 RS Gear Shift
KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b660", MODE="0660", TAG+="uaccess"

Thanks guys, i confirm this is working for me to, using a Logitech G923 PS/PC version and a Thrustmaster Farmstick xbox.
My steam launch options: PROTON_ENABLE_HIDRAW=0x046d/0xc266,0x044f/0x041b mangohud %command%

and a "60-steam-imput.rules" file with:
#Logitech G923 PS/PC
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c266", MODE="0660", TAG+="uaccess"
#Thrustmaster farmstick xbox version
KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="041b", MODE="0660", TAG+="uaccess"

I don´t have FFB in Farming, but since the force feedback in the game is not outstanding at all, it's not a problem for me, only use Oversteer for set the autocenter in 15 and woks fine. finally no more windows for me...

Hello
I'm having the same issues as described above, the wheel turns only to right.
I have the Logitech (still Saitek underneath) heavy duty set the control panel seams to work after trying but the wheel and pedals are still unusable. Turning down to proton 6.x is impossible since that crashes the game. I tried @kjsmita6 and @Ekzilit solutions but they didn't seam to work. Can anybody help?
Thanks

output of lsusb:
Bus 001 Device 005: ID 0738:2217 Mad Catz, Inc. Saitek Heavy Eqpt. Wheel & Pedal

my udev file:

# Farmwheel
KERNEL=="hidraw*", ATTRS{idVendor}=="0738", ATTRS{idProduct}=="2217", MODE="0660", TAG+="uaccess"

Replying to https://github.com/ValveSoftware/Proton/issues/8671#issuecomment-3330245223

Did you add the PROTON_ENABLE_HIDRAW to the launch options? You might also need to restart your computer after adding the udev rules.

Yes I added it. Restarted the udev and computer several times. Maybe I will try to reinstall the fs25, that solved some issues in the past with different games.

Nope the reinstalation didn't solve anything, even using logitech EX racing wheel instead of the saitek one still having the same output.

I recently noticed that on newer proton versions I get blurry textures. Anyone else experience this? I haven't found any recent mentions of this issue for any game.
Proton 8:

Proton 9/10/Experimental:

Note the VRAM stats on the 3rd picture in both case.

@rLy07 Thank you for the report! I took a look and this seems to be a change in vkd3d-proton and might also only impact some GPUs.

Nope the reinstalation didn't solve anything, even using logitech EX racing wheel instead of the saitek one still having the same output.

Did you ever find a solution, im trying to make this work with my Thrustmaster T300 GT RS all my racing games are working but not FS22 and FS25 they only turn right.

I have made an udev rule called 60-wheel.rules with the the parameters suggested and the Hidraw launch command in Steam but it still doesnt work.

Replying to https://github.com/ValveSoftware/Proton/issues/8671#issuecomment-3541156836

Unfortunately not. Even used Warp AI to try to solve it but unfortunately it is still not working. I thought about reinstalling the whole system later but didn't have time to do it yet.

I have an idea for a workaround but it might only work for some wheelbases. Basically, we don't want SDL becasue it always normalizes axes to -1:1 which ends un as -23768:32767 on the "windows" side but we don't want hidraw as that works around the driver. Hidraw should actually still provide ffb for USB PID bases like Moza, Conspit, Cammus etc but it's currently broken XD

So we could use udev input and I'll report back since moza changed the steering axis to be 0:65535 some time ago

Guys, I might have a fix that will enable Input AND still provide force feedback through default SDL, no need to muck around with Hidraw. I'm messing around with Project Motor Racing and it has the same issues, but I managed to overcome them. I'll post the workaround later if it will work.

Lawstorant, I'm very interested. I also use a Moza Wheelbase R5. Did it work, and if so, can you explain how?

I just got this working using the launch option PROTON_ENABLE_HIDRAW=1 and nothing else. I started creating the udev rule for it, but I wasn't sure if I was doing it right and my plugdev group didn't exist so without rebooting I figured "what the hell" and tried it.

No compatibility mode or proton and it works perfectly.

Logitech G920 plugged into a USB hub. Fedora 43. Steam 1763795278. FS25 Version 1.15.0.0

I have since deleted the udev rule from where I put it /etc/udev/rules.d/40-usb_modeswitch.rules and rebooted, updated my OS, then tried again without changing the launch options and it still works perfectly.

Edit: I forgot FFB is supposed to be working, so this is not "working perfectly" as I originally stated. I have no working FFB, but the wheel and pedals work as expected for general control.

@mathis996 unfortunately, no. I wasn't able to force directInput backend like in Project Motor Racing. I'll try some more, but currently nothing.

@dboling19 I wouldn't say works perfectly if it doesn't have FFB

@dboling19 I wouldn't say works perfectly if it doesn't have FFB

Yes, my bad. I forgot there should be FFB. I am coming from FS19. No, FFB is not working.

Hi all, I have a logitech heavy equipment bundle that seems to be working after a couple changes I made in code. I was able to fix the steering hard-right on left input issue by changing some code in the wine repo (for my local builds).

wine/dlls/winebus.sys/bus_sdl.c

371:        &absolute_usages[i].Usage, FALSE, 0, 32767)) // Changed from -32767 to 0 (could probably be 0 to 65535
...
// Change the SDL mapping to convert from a signed int to unsigned (I guess their rawinput doesn't play well with negative values)
// (also this is bad code, I just wanted it to work at this point. Ignore the tab spacing that's just copy-paste acting up.)
837:        			LONG new_value = ie->value;
838: 
839:                		new_value = (new_value >> 1) + (32768 >> 1);
840:
841:                        	ERR("JoyAxisEvent: %d\n", (int) new_value);
...

I also had an issue with forcing dinput on the side panel, and was able to fix this in the same file by adding a case to prevent winebus from creating it as a gamepad:

wine/dlls/winebus.sys/bus_sdl.c

1024:		if (pSDL_JoystickGetVendor(joystick) == 0x738)
1025:			desc.is_gamepad = FALSE;

I'm not really sure what the path for fixing all these different devices would look like, but hopefully this can at least help a bit.

@andymadden Could you elaborate a bit on the bit starting at line 837, please? the lines don't really add up for me. Are you editing the SDL_JOYAXISMOTION case in the set_report_from_joystick_event function?

@Kurotsune77 - Yes that's exactly where I did that. I'm just converting the value from signed to some unsigned value based on the HID range on line 371.

Anyone working on a solution for this ?

I installed Debian today and tested my thrustmasters with Proton Experimental, I then switched to Ubuntu and retested with the same results on my thrustmasters now working. The g29 logitech steering wheel "worked". The brake pedal seems to be always pressed in the game, out of the game it's fine. I just put the manual forward and reverse and was enough of a work around for me to be satisfied with a mild annoyance but still functioning game play.

I tried switching between PS3 and PS4 on the wheel as well as unplugging and plugging back in.

I can also confirm this issue. The Saitek Side Panel is detected as XINPUT_GAMEPAD.
I also tested with different proton version and its happend every time, thats i got only the XINPUT_GAMEPAD.
Kernel: 6.17.0-14-generic
I created also a udev rule for this device
KERNEL=="hidraw*", ATTRS{idVendor}=="0738", ATTRS{idProduct}=="2218", MODE="0660", TAG+="uaccess"
And as a start parameter i set PROTON_ENABLE_HIDRAW=1

steam-2300320.log

Also when i test it with jstest /dev/input/js0 its show me all buttons...

anymadden,

Would you be able to elaborate on how this was accomplished? I'd like to try your modification to see if it'll work with mechwarrior 5. The game seems to think I am maxing out the movement on my VKB Gladiator as soon as I touch it, and it is unplayable. What you are describing in your post resembles what I am experiencing.

That being said, I have no idea how to go about implementing your fix.
I found the winebus.sys file in:
/opt/wine-staging/lib64/wine/x86_64-windows/
But am not sure if that's correct, or even what program to use to edit it.
Thank you for any information.

wine/dlls/winebus.sys/bus_sdl.c

Same issue on Linux Mint 22.3 and different Proton versions, side panel is recognized as XINPUT_GAMEPAD and only half the buttons work. jstest does show all axis and buttons.

@hyper1on - I didn't make any direct changes to winebus.sys. Instead I made those changes in bus_sdl.c and then built proton from scratch and added my custom proton version to steam.

If you know the VID/PID for the device, you can also do this with any other controller that's "falsely" recognized as an xinput gamepad. I haven't had the time to write a PR for Wine, The weird catch is that even if it recognizes the device, you may have to remap it from SDL's integer mapping to whatever mapping that game supports (unsigned int or signed int).

I have try it and add to this file, which you mention, that's the device (Saitek Heavy equipment side panel) is detected as direct input device, which joy.cpl show me, but still the game show me only the driving wheel and not the side panel.

That's so annoying :/ I can share what I have try .