Kimplul
No FFB in American Truck Simulator
Hi @mercster, I took the liberty of making a new issue for you. The original issue you posted under was resolved by an apparent difference between sending USB/HID packets and different revisions of the wheel responding in different ways, and I would assume/hope that that is not relevant here :)
Unfortunately I am also seeing this behavior with my newly purchased T300RS GT. Oversteer can change things on the wheel, but I enter a game (American Truck Simulator)... I have no effects, just autocenter. fftest can do the 1, 4, and 5 "rumble" type effects, but the other ones do nothing. (Again, oversteer CAN change force feedback strength, autocenter, etc.) Even turning off FF in ATS completely, no change, just slightly stiff wheel with strong autocenter.
I know that Euro Truck Simulator works, and as far as I can tell American Truck Simulator uses the same engine so I would expect it to work as well but I don't have it to test with. Since you have some FFB with fftest I would guess that the issue is either in the game or Steam or some underlying system behaving weird. Though 1, 4, 5 is kind of an odd set, usually I would expect at least 2 to work as well but if you have a strong autocentering it might not be super apparent.
Probably not directly related, but in https://github.com/Kimplul/hid-tmff2/issues/132 I found out that having the uaccess bit set seemed to break button input with SDL, which is used lots and lots of programs/games/whatever. Could be something similar again, really don't know, but removing write/read permissions on /dev/hidraw? could be worth a shot.
Just to check, did you upgrade the wheel's firmware? It has to be done via Windows unfortunately, and I thought we had found that every version after 31 would work, so the driver not loudly complaining probably means this isn't the issue, but might be worth checking.
Sidenote, must be frustrating getting a new toy and finding out it doesn't work. Sorry about that.
When I boot, hit-tminit-new and usb-tminit-new do not get loaded, only hid-tmff-new. Not sure why.. also I have seen no mention from anyone of the usb-tminit-new module that gets built.. which of all these should be loaded and in what order?
It's a bit complicated, but some wheels show up as just 'plain' USB devices, whereas some wheels show up as HID devices, which 'happen' to be USB devices. As far as I know, there's no way to have a single driver handle both cases, so there's both hid-tminit-new and usb-tminit-new. What's more, there's an in-kernel counterpart that doesn't support some newer wheels (that's probably changing in the near future luckily), hid-thrustmaster, which should work just fine for the T300RS.
hid-tminit-new/usb-tminit-new/hid-thrustmaster gets loaded first, and it just tells the wheel to restart itself and 'do it properly this time'. Most (but not all, annoyingly) Thrustmaster wheels initially show up as Thrustmaster Thrustmaster FFB Wheel and require that the host send it some initialization packets before it shows up what it 'actually' is, T300 or whatever.
Wheel is is turned to "PC Mode" (same as PS3 mode.)
dmesg output when plugging in device:
[ 2919.740709] usb 1-9: new full-speed USB device number 20 using xhci_hcd [ 2919.865262] usb 1-9: New USB device found, idVendor=044f, idProduct=b65d, bcdDevice= 1.00 [ 2919.865278] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2919.865285] usb 1-9: Product: Thrustmaster FFB Wheel [ 2919.865291] usb 1-9: Manufacturer: Thrustmaster [ 2919.871287] input: Thrustmaster Thrustmaster FFB Wheel as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:044F:B65D.0010/input/input47 [ 2919.871494] hid-thrustmaster 0003:044F:B65D.0010: input,hidraw4: USB HID v1.00 Gamepad [Thrustmaster Thrustmaster FFB Wheel] on usb-0000:00:14.0-9/input0 [ 2919.891416] usbhid 1-9:1.0: Wheel with (model, attachment) = (0x2, 0x6) is a Thrustmaster T300RS. attachment_found=1 [ 2919.891676] usbhid 1-9:1.0: Success, the wheel should have been initialized! [ 2919.891716] usb 1-9: USB disconnect, device number 20 [ 2920.511696] usb 1-9: new full-speed USB device number 21 using xhci_hcd [ 2920.637034] usb 1-9: New USB device found, idVendor=044f, idProduct=b66e, bcdDevice= 1.00 [ 2920.637051] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2920.637058] usb 1-9: Product: Thrustmaster T300RS Racing wheel [ 2920.637063] usb 1-9: Manufacturer: Thrustmaster [ 2920.642629] input: Thrustmaster Thrustmaster T300RS Racing wheel as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/0003:044F:B66E.0011/input/input48 [ 2920.643393] tmff2 0003:044F:B66E.0011: input,hidraw4: USB HID v1.11 Joystick [Thrustmaster Thrustmaster T300RS Racing wheel] on usb-0000:00:14.0-9/input0 [ 2920.643757] tmff2 0003:044F:B66E.0011: force feedback for T300RS
merc@fedora:~$ lsmod | grep tm | grep new hid_tmff_new 77824 0 hid_tminit_new 20480 0 usb_tminit_new 16384 0merc@fedora:/etc/udev/rules.d$ lsusb | grep Thrust Bus 001 Device 021: ID 044f:b66e ThrustMaster, Inc. Thrustmaster T300RS Racing wheelI also modprobe'd usb_tminit_new in case it was supposed to do anything, but no difference. hid-thrustmaster is blacklisted, I've rebooted/plugged/unplugged wheel several times.
This all looks expected, as far as I can tell.
Originally posted by @mercster in #5
I also modprobe'd usb_tminit_new in case it was supposed to do anything, but no difference.
Oh, right, missed this. dmesg doesn't show the module name, it shows whatever name is set in the .name field of the driver, which is still hid-thrustmaster for hid-tminit-new, see https://github.com/Kimplul/hid-tminit/blob/860def3eef4e1079564088edff0962ba80fe22d9/usb-tminit.c#L44
That is admittedly confusing for no good reason, I initially expected to use hid/usb-tminit-new as just a temporary stopgap (and I'm still hoping that's what they are, just for a rather long 'temporary') so I guess I just didn't bother changing stuff that wasn't directly related to functionality.
Hi @mercster, I took the liberty of making a new issue for you. The original issue you posted under was resolved by an apparent difference between sending USB/HID packets and different revisions of the wheel responding in different ways, and I would assume/hope that that is not relevant here :)
No worries mate... thank you for not only writing this cool driver, but also being very engaged and answering end users with piddly problems, it's very much appreciated!
I know that Euro Truck Simulator works, and as far as I can tell American Truck Simulator uses the same engine so I would expect it to work as well but I don't have it to test with. Since you have some FFB with
fftestI would guess that the issue is either in the game or Steam or some underlying system behaving weird. Though 1, 4, 5 is kind of an odd set, usually I would expect at least 2 to work as well but if you have a strong autocentering it might not be super apparent.
I actually got somewhere, I was playing and thinking it wasnt working, then drove over some "rough ground" and to my surprise, the wheel gave a low rumble! I think maybe a combination of a) a wonky USB port, b) hid-tminit-new not being loaded before hid-tmff2-new, c) possibly overdrive (see below), and d) not knowing what behavior to expect out of ATS.
It's kinda working, although testing it out by, for instance, setting gain and everything to "100%" doesn't seem to act the way I would expect.
Which also brings me to oversteer... I don't understand the nature of this program. Do things you set there persist after exiting oversteer? How does one "remove" any of the tweaks you've made in oversteer (aka factory default levels)? I think maybe I was setting things too low in oversteer, and then setting things kinda medium in the video game (ATS), and oversteer was making it so whatever I set in ATS was limited (i.e., I can set 100% gain, but because something was wonky in oversteer, the effect was very weak.)
As far as fftest goes, I misremembered: 0, 4, and 5 work (sinusoidal, strong rumble, weak rumble.) Even with the wheel "kinda sorta" working in ATS, 1-3 do nothing discernible (though... maybe something oversteer set is minimizing it? Bluh.)
Probably not directly related, but in #132 I found out that having the
uaccessbit set seemed to break button input with SDL, which is used lots and lots of programs/games/whatever. Could be something similar again, really don't know, but removing write/read permissions on/dev/hidraw?could be worth a shot.
I'll have a look at that, but I'm pretty sure perms aren't the problem, at this point.
Just to check, did you upgrade the wheel's firmware? It has to be done via Windows unfortunately, and I thought we had found that every version after 31 would work, so the driver not loudly complaining probably means this isn't the issue, but might be worth checking.
I did not. I know I should. It's just a massive hassle, since I will have to install Windows on a secondary drive, probably screw up GRUB on my main drive, have to rescue that, etc etc.
One thing that is strange (and maybe caused by non-updated drivers...): all of the udev "rules" files that I have say that the T300RS GT (which I have) should have product ID of b66d, but my wheel's product ID is b66e (standard T300RS.) I think this might be due to it being switched to "PC" rather than "PS4/PS5" (is that maybe what tminit/tmff2 wants? Confused on this point too.) Maybe if I updated the driver (to v34 I guess) I would get the prodID of b66d.
Sidenote, must be frustrating getting a new toy and finding out it doesn't work. Sorry about that.
Again, thanks so much for your work and support, none of us would be having any fun with these without your superb driver.
It's a bit complicated, but some wheels show up as just 'plain' USB devices, whereas some wheels show up as HID devices, which 'happen' to be USB devices. As far as I know, there's no way to have a single driver handle both cases, so there's both
hid-tminit-newandusb-tminit-new. What's more, there's an in-kernel counterpart that doesn't support some newer wheels (that's probably changing in the near future luckily),hid-thrustmaster, which should work just fine for the T300RS.
hid-tminit-new/usb-tminit-new/hid-thrustmastergets loaded first, and it just tells the wheel to restart itself and 'do it properly this time'. Most (but not all, annoyingly) Thrustmaster wheels initially show up asThrustmaster Thrustmaster FFB Wheeland require that the host send it some initialization packets before it shows up what it 'actually' is, T300 or whatever.
merc@fedora:/usr/lib/modules/6.15.5-200.fc42.x86_64/extra$ ls -l
total 76
-rw-r--r--. 1 root root 31516 Jul 12 12:11 hid-logitech.ko.xz
-rw-r--r--. 1 root root 22716 Jul 13 14:54 hid-tmff-new.ko.xz
-rw-r--r--. 1 root root 5872 Jul 13 14:54 hid-tminit-new.ko.xz
drwxr-xr-x. 2 root root 4096 Jul 12 14:10 nvidia
-rw-r--r--. 1 root root 5692 Jul 13 14:54 usb-tminit-new.ko.xz
So... since it looks like my device is being recognized as HID, I do not need/should not load usb-tminit-new? Also, I'm still flummoxed as to why udev is loading the hid-tmff-new without first loading hid-tminit-new. I think that was the cause of some of my early problems. I need to somehow force the load order, 1) hid-tminit-new 2) hid-tmff-new. I can post contents of the two udev rules files I have installed if it might clear anything up:
merc@fedora:/etc/udev/rules.d$ ls -l *thrust*
-rw-r--r--. 1 root root 3293 Jul 11 15:33 99-thrustmaster.rules
-rw-r--r--. 1 merc merc 2092 Jul 10 17:29 99-thrustmaster-wheel-perms.rules
This all looks expected, as far as I can tell.
Nod, I see nothing out of the ordinary either.
Oh, right, missed this.
dmesgdoesn't show the module name, it shows whatever name is set in the.namefield of the driver, which is stillhid-thrustmasterforhid-tminit-new, see https://github.com/Kimplul/hid-tminit/blob/860def3eef4e1079564088edff0962ba80fe22d9/usb-tminit.c#L44That is admittedly confusing for no good reason, I initially expected to use
hid/usb-tminit-newas just a temporary stopgap (and I'm still hoping that's what they are, just for a rather long 'temporary') so I guess I just didn't bother changing stuff that wasn't directly related to functionality.
Yeah I gathered all that, blacklisted hid-thrustmaster, etc. No confusion there, I know the logs and module names aren't lining up exactly.
Cheers!
EDIT: Fixed hid-tminit-new loading first with softdep hid-tmff-new pre: hid-tminit-new in /etc/modprobe.d
Do you have any other games besides ATS that you could test? DiRT Rally is what I've played the most, and I feel like it's pretty much how the wheel should behave. Speed Dreams is free software and should also work well out of the box, though its FFB system is maybe not as advanced/accurate as DiRT and feels a bit 'floaty' to me, but could be a good point of comparison.
Which also brings me to oversteer... I don't understand the nature of this program. Do things you set there persist after exiting oversteer? How does one "remove" any of the tweaks you've made in oversteer (aka factory default levels)? I think maybe I was setting things too low in oversteer, and then setting things kinda medium in the video game (ATS), and oversteer was making it so whatever I set in ATS was limited (i.e., I can set 100% gain, but because something was wonky in oversteer, the effect was very weak.)
Yes, settings persist after closing Oversteer. Some settings are saved in the kernel module as parameters, like the spring/damper/friction levels, and some are just sent straight to the wheel, like the range, autocentering and gain. The only way to fully reset all values, as far as I can tell, is to unplug your wheel and restart your computer, so that the kernel module gets unloaded and the wheel's memory is reset. Probably a good idea to try setting all Oversteer parameters to 100% and see what happens, though I'm personally not quite convinced that would solve things. The default values for Oversteer parameters are around 20% IIRC, which is maybe on the low side but shouldn't be imperceptible by any means.
It's just a massive hassle, since I will have to install Windows on a secondary drive, probably screw up GRUB on my main drive, have to rescue that, etc etc.
Virtual machines work as well, which is less of a hassle but admittedly the situation is not perfect. There were some ideas floated around for a Linux firmware upgrade tool, but there are some (potentially legal) issues of getting hands on the actual firmware binaries and redistributing them, which kind of killed the idea off last time around.
One thing that is strange (and maybe caused by non-updated drivers...): all of the udev "rules" files that I have say that the T300RS GT (which I have) should have product ID of b66d, but my wheel's product ID is b66e (standard T300RS.) I think this might be due to it being switched to "PC" rather than "PS4/PS5" (is that maybe what tminit/tmff2 wants? Confused on this point too.) Maybe if I updated the driver (to v34 I guess) I would get the prodID of b66d.
That's related to the PS3/PS4 mode of the wheel, PS3 (so 'PC' mode) shows up as b66e, the PS4 mode shows up as b66d, see udev/99-thrustmaster.rules for example. The PS4 mode should work as well, but I would generally recommend sticking to the PS3 mode since there's probably fewer surprises with it. Some games might potentially expect PS3/PC mode wheels and don't really know what to do with something that claims to be for the PS4, but that hasn't really been confirmed to be an issue as far as I can tell. Switching modes might also be something worth trying, at least it would be fairly quick, though I don't expect it to fix anything unfortunately.
So... since it looks like my device is being recognized as HID, I do not need/should not load usb-tminit-new? Also, I'm still flummoxed as to why udev is loading the hid-tmff-new without first loading hid-tminit-new. I think that was the cause of some of my early problems. I need to somehow force the load order, 1) hid-tminit-new 2) hid-tmff-new. I can post contents of the two udev rules files I have installed if it might clear anything up:
You don't need to load usb-timinit-new since your wheel is a HID device, correct. I would also say that you don't really need to force loading hid-tminit-new either because hid-thrustmaster (in the kernel) knows how to handle the T300RS just fine, but it shouldn't hurt either.
To be pedantic, it's not udev that chooses which driver to load, it's moreso that udev gets called once a device has been 'accepted' (probably not the right word) by the kernel, which is done by loading a driver for it. I guess you could also write a udev rule to manually load a new module with modprobe if a certain device shows up and potentially force bind it, but I suspect that's not really the intended usage.
Please do post the udev rules you have, I'm curious.
Do you have any other games besides ATS that you could test? DiRT Rally is what I've played the most, and I feel like it's pretty much how the wheel should behave. Speed Dreams is free software and should also work well out of the box, though its FFB system is maybe not as advanced/accurate as DiRT and feels a bit 'floaty' to me, but could be a good point of comparison.
I have Assetto Corsa, just haven't set it up yet (apparently it's a bit of a hassle to get it up and going on Linux; nothing I can't handle, just lazy.)
Yes, settings persist after closing Oversteer. Some settings are saved in the kernel module as parameters, like the spring/damper/friction levels, and some are just sent straight to the wheel, like the range, autocentering and gain. The only way to fully reset all values, as far as I can tell, is to unplug your wheel and restart your computer, so that the kernel module gets unloaded and the wheel's memory is reset. Probably a good idea to try setting all Oversteer parameters to 100% and see what happens, though I'm personally not quite convinced that would solve things. The default values for Oversteer parameters are around 20% IIRC, which is maybe on the low side but shouldn't be imperceptible by any means.
Funny thing, if I run Oversteer, apply some settings, and close, the settings persist. But if I open up Oversteer again, it "resets" or something, and goes back to the normal ~20% values.
I set my Oversteer to 100% (oversteer github guy also told me to try; makes, sense, let the game control the wheel, right?) And that's a hard no go. If I set everything to 100 in oversteer, I can turn down everything to 0 in ATS and the wheel is still extremely hard to turn. Like, I would be afraid of breaking something, the mount, etc. So I don't know exactly how the wheel's settings, the driver, oversteer, and the game all interact (quite confusing, multiple moving parts), but at least for ATS, leaving the oversteer at the default values seems best.
Virtual machines work as well, which is less of a hassle but admittedly the situation is not perfect. There were some ideas floated around for a Linux firmware upgrade tool, but there are some (potentially legal) issues of getting hands on the actual firmware binaries and redistributing them, which kind of killed the idea off last time around.
I read that nightmare story of the guy who tried updating wheel firmware with VM and USB passthrough, and bricking the wheel until he could go back in Windows and reinstall drivers/firmware. While I do wanna update the wheel (maybe use a friend's PC), it's basically working at this point, so the VM thing sounds like a risk.
That's related to the PS3/PS4 mode of the wheel, PS3 (so 'PC' mode) shows up as
b66e, the PS4 mode shows up asb66d, seeudev/99-thrustmaster.rulesfor example. The PS4 mode should work as well, but I would generally recommend sticking to the PS3 mode since there's probably fewer surprises with it. Some games might potentially expect PS3/PC mode wheels and don't really know what to do with something that claims to be for the PS4, but that hasn't really been confirmed to be an issue as far as I can tell. Switching modes might also be something worth trying, at least it would be fairly quick, though I don't expect it to fix anything unfortunately.
OK, gotcha. Nah PC mode seems to be working fine, but yeah, wonder what difference other mode would make, I could test it for you.
You don't need to load
usb-timinit-newsince your wheel is a HID device, correct. I would also say that you don't really need to force loadinghid-tminit-neweither becausehid-thrustmaster(in the kernel) knows how to handle the T300RS just fine, but it shouldn't hurt either.
Hmm... at one point I thought it needed to be loaded, and prior to the tmff... then again, my testing methodology sucks cuz I was changing more than one thing at a time, switching to better USB port, etc etc... I'll take your word for it. :-)
To be pedantic, it's not
udevthat chooses which driver to load, it's moreso thatudevgets called once a device has been 'accepted' (probably not the right word) by the kernel, which is done by loading a driver for it. I guess you could also write audevrule to manually load a new module withmodprobeif a certain device shows up and potentially force bind it, but I suspect that's not really the intended usage.
Yeah, gotcha.
Please do post the
udevrules you have, I'm curious.
Sure.. they are just the permissions one that gets distributed with oversteer:
# Thrustmaster T300RS Racing Wheel (USB)
ATTRS{idProduct}=="b66e", RUN+="/bin/sh -c 'cd %S%p; chmod 666 range gain spring_level damper_level friction_level alternate_modes'"
(I have no idea what it's doing there, calling shell and passing %S%p, which apparently /sys fs things I know nothing about, man page for udev wasnt particularly helpful.)
And the script your driver comes with:
# T300RS PS3 normal mode
# remove deadzone for both evdev and jsdev subsystems
SUBSYSTEM=="input", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b66e", RUN+="/usr/bin/evdev-joystick --evdev %E{DEVNAME} --deadzone 0"
SUBSYSTEM=="input", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b66e", RUN+="/usr/bin/jscal -s 6,1,1,32767,32767,16384,16384,1,3,448,574,1394469,1394469,1,3,448,574,1394469,1394469,1,3,448,574,1394469,1394469,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912 /dev/input/js%n"
(Only relevant lines shown for brevity.) I will note both of these are assigned '99' in the udev load order scheme... should one necessarily go before the other?
Thanks again.
I set my Oversteer to 100% (oversteer github guy also told me to try; makes, sense, let the game control the wheel, right?) And that's a hard no go. If I set everything to 100 in oversteer, I can turn down everything to 0 in ATS and the wheel is still extremely hard to turn. Like, I would be afraid of breaking something, the mount, etc. So I don't know exactly how the wheel's settings, the driver, oversteer, and the game all interact (quite confusing, multiple moving parts), but at least for ATS, leaving the oversteer at the default values seems best.
Just to check, did you also set the autocentering to 100%? Some games seem to let the system decide on autocentering strength whereas others try to set it themselves, see https://github.com/ValveSoftware/Proton/issues/8395#issuecomment-2851373404 for example. Seems like ATS didn't try to change the autocentering, meaning you'd be left with full force all the time. Sorry, poorly worded by me when I said 'all Oversteer parameters', I apparently implicitly excluded autocentering.
From the thread, it also seems that Proton 10 handles autocentering slightly differently than Proton 9, could also be worth trying out a few different versions to see if there are differences.
I read that nightmare story of the guy who tried updating wheel firmware with VM and USB passthrough, and bricking the wheel until he could go back in Windows and reinstall drivers/firmware. While I do wanna update the wheel (maybe use a friend's PC), it's basically working at this point, so the VM thing sounds like a risk.
Do you happen to have a link to the post? I don't remember hearing about VMs bricking wheels, and I'm curious about the details since I've updated the firmware of my wheel a few times without any issues. Regardless, I doubt the firmware is an issue in this situation and being hesitant to update it makes sense, but I can't be 100% sure it's not a factor. Binary blobs are fun, eh? :)
[...] (I have no idea what it's doing there, calling shell and passing %S%p, which apparently /sys fs things I know nothing about, man page for udev wasnt particularly helpful.) [...] (Only relevant lines shown for brevity.) I will note both of these are assigned '99' in the udev load order scheme... should one necessarily go before the other?
Yeah, udev doesn't have the best documentation around unfortunately. Roughly speaking, the driver creates a number of files that Oversteer uses to configure the wheel, and %S%p expands to the directory where those files are. Setting chmod 0660 for the different files just allows Oversteer to run without root.
The second file is just for eliminating the deadzone that is by default applied to all joysticks. Someone pointed out to me that devices are technically able to request their own deadzone values without any external udev rules, but I haven't implemented that for this module (yet).
These files are orthogonal and don't affect eachother, so they can both be99-... just fine.
Anycase, udev rules look fine. I initially got curious when you mentioned one referring to the T300RS by b66d, but I guess that was cleared up by the PS3/PS4 difference?
Oh, I just remembered, ETS2 has a Linux native and Proton version, does ATS also have two separate versions? Which one have you been using, and what does the other version do (if it exists)? Please do also report back if you try out Assetto Corsa or Speed Dreams.
Just to check, did you also set the autocentering to 100%? Some games seem to let the system decide on autocentering strength whereas others try to set it themselves, see ValveSoftware/Proton#8395 (comment) for example. Seems like ATS didn't try to change the autocentering, meaning you'd be left with full force all the time. Sorry, poorly worded by me when I said 'all Oversteer parameters', I apparently implicitly excluded autocentering.
No, autocenter set to default (0). Everything else to 100.
From the thread, it also seems that Proton 10 handles autocentering slightly differently than Proton 9, could also be worth trying out a few different versions to see if there are differences.
I'm using GE-Proton-10.x as of now, I guess I could try some 9-x releases.
Do you happen to have a link to the post? I don't remember hearing about VMs bricking wheels, and I'm curious about the details since I've updated the firmware of my wheel a few times without any issues. Regardless, I doubt the firmware is an issue in this situation and being hesitant to update it makes sense, but I can't be 100% sure it's not a factor. Binary blobs are fun, eh? :)
Ah, it wasn't on github:
https://forum.level1techs.com/t/solved-thrustmaster-t300rs-gt-linux-hid-failure-register-as-bootloader-fix/194991/3
These files are orthogonal and don't affect eachother, so they can both be
99-...just fine.
Ok!
Anycase,
udevrules look fine. I initially got curious when you mentioned one referring to the T300RS byb66d, but I guess that was cleared up by the PS3/PS4 difference?
No, I haven't checked PS4/5 mode. I'll do that later today and let you know.
Oh, I just remembered, ETS2 has a Linux native and Proton version, does ATS also have two separate versions? Which one have you been using, and what does the other version do (if it exists)? Please do also report back if you try out Assetto Corsa or Speed Dreams.
ATS does have a native mode, but noone uses it (that I know of.) Most poeple run through proton, as I am doing. I got Assetto Corsa up and running and the force feedback is actually very good. As I haven't played much of it while in Windows, I don't know how "accurate" it's being, but it feels like what I would imagine it should feel like. Cheers!