Closed delauflahm closed 1 month ago
In the dmesg
log the wheel reports itself as having PID 0xb66e
, but you say lsusb
shows it as 0xb66d
. 0xb66d
is the ID the wheel shows up as when in PS4 mode, I'm guessing you already tried reattaching the wheel with the slider set to PS3 on the wheel base?
I don't think those errors are fatal because it installed successfully.
Yeah, SSL errors are expected when not signing the module. Shouldn't matter in your case, modprobe
would've spat out an error if it refused to load the modules.
In the dmesg log the wheel reports itself as having PID 0xb66e, but you say lsusb shows it as 0xb66d. 0xb66d is the ID the wheel shows up as when in PS4 mode, I'm guessing you already tried reattaching the wheel with the slider set to PS3 on the wheel base?
Yes i plugged it in with PS4 Mode and when it's plugged in with PS3 Mode it's
044f:b66e
.
You should only use the wheel in PS3 mode. PS4 mode won't work. Also relevant: what is your wheel's fw version? You can check that in the windows driver.
Yes, when I tested it the first time I didn't know I have to use it in the PS3 Mode. Back then the screenshot was made - I'm sorry. At this time it's plugged in with PS3 Mode. My Firmware Version 31.
PS4 mode support is sort of work in progress over in the ps4
branch, but I recommend sticking to PS3 mode for now.
Correct me if I'm wrong, but the issue here is that the wheel's rotation and pedal axes aren't being recognised in Forza Horizon 5 and/or steam? Could you try closing down steam completely and checking if the axes are recognised in jstest-gtk
?
Yes that's right. I first have to install this but I have some problems with installing sigc++ first. Is there anything easier than this?
EDIT: Never mind I installed sigc++ successfully.
jstest-gtk
is in Ubuntu's repos, so running sudo apt install jstest-gtk
should install all dependencies. If you want to manually compile sigc++
, seems that you need xsltproc
, maybe some other programs as well.
Okay, jstest-gtk
detects the steering wheel. (with buttons, shifters, pedals, steering axes)
Right, that's good. I can't get steam to recognise the wheel as a gamepad at all, is it still being recognised as a gamepad by your steam?
No Steam does not recognise the wheel at all - no controller detected.
Alright, and what does FH5 do?
I can't bind any Buttons etc. to an action.
Right, I see from protondb that the game has problems detecting several different kinds of controllers, mostly Xbox but other wheels as well. Do you have other racing games that you could test so we can check if this is an issue with Proton/FH5 running under Proton?
In Dirt 4 the steering wheel the same problem occurred.
Dirt 4 running natively for some reason refuses to acknowledge the T300RS, yes, but running under Proton it seems to work. For some reason I can't change the menu mappings, which leads to the sort of awkward situation where the game assumes the T300RS uses an axes that Proton doesn't seem to be providing to it, so some menus behave as if the user is scrolling down. Really weird.
Since SDL doesn't report wheel device types, Feral ports rely on profile files to detect wheels and define their mappings. I guess it's a profile file missing for that wheel. Profiles are XML files esily editable in case you want to give it a shot.
Do you have any resources on how exactly I should go about adding a mapping file? Seems like there is some kind feral
folder in actionmaps
, I'm guessing this is where Feral look for the mappings but adding a file for the t300rs doesn't seem to do anything. There also seems to be some kind of vfs-config.xml
which copies files to actionmaps/feral
, but adding in the t300rs
there didn't do anything either. What am I missing?
EDIT: Maybe found it. There's a file called inputdevices.json
, which was missing the T300, now the inputs are detected. Will test more.
Alright, wrt. DiRT 4, to get it behaving nicely natively I just had to add
{
"Name": "Thrustmaster T300 RS",
"VendorID": "0x044f",
"ProductIDs": [
"0xb66e"
],
"Category": "Wheel",
"Type": "ThrustmasterWheel"
},
to share/inputdevices.json
in the DiRT 4 game files. You can access them by right-clicking on DiRT 4 in Steam and going to Properties > LOCAL FILES > Browse.
I should maybe contact Feral and ask them to add the wheel to the list by default.
There's still the annoying thing that I can't remap the menu navigation buttons for some reason, so I just remapped the pedals in the driver itself, seems to fix things. Currently top of ps4 branch. EDIT: To clarify, I'm assuming the changed mappings are more-or-less the intended mappings, as the game shows gas and brake icons for the new axes. No icon for clutch though, but the game's default mapping picks up all the axes correctly so I'm guessing it's fine.
As for Forza, I'm 90 % sure the issue is with Proton, as protondb has multiple reports of it having issues detecting other input devices. Some claim that using Glorious Eggroll's Proton fork fixes it for them, but if it's too much of a hassle to install I would just wait for Proton to get updated, GE's patches usually get upstreamed fairly quickly.
I don't have Dirt4 installed but you found it. I know DR and GA worked similarly.
I doubt Feral cares anymore about those ports but worth trying. If not, maybe you could add it as a diff file to your project with installation instructions.
The new mapping isn't used by any other wheel. Old Logitech wheels use Y (gas), Z (brakes) and RZ (clutch) while most modern wheels since the G25 use Z (gas), RZ (brakes) and Y (clutch). The Fanatec wheels use this mapping too.
I think there must be some way to let the game know which axes to use.
most modern wheels since the G25 use Z (gas), RZ (brakes) and Y (clutch). The Fanatec wheels use this mapping too.
Thrustmaster having their own way of doing things, who would've thought?
I think there must be some way to let the game know which axes to use.
I'd hope so, it's really weird seeing lots of mapping entries but them being greyed out. I tried looking for some config or 'advanced mapping settings' or whatever but just couldn't find anything like it. I can probably try snooping around a bit more, but it really does seem like they're hard-coded. Maybe the DiRT 4 mapping files have something to do with it, but seems kind of dumb to require the user to manually modify xml files for something like this.
Alright, yes, modifying the xml files can actually change which axes the menu navigation uses. Now I'm a bit torn between what I should do, should I keep the wheel's axes the same as DiRT 4 expects them (as I assume they are the axes the Windows driver uses) or should I use the axes most other modern wheels use?
In the case of DiRT 4, we can somewhat cumbersomely remap the inputs to use more typical mappings, but I don't know if there are other games that make more immutable assumptions about wheels and wheel mappings. On the other hand, using more typical mappings might help in other games that aren't as strict about wheel model etc.
EDIT: Or should I add in a module parameter that chooses which mapping to use?
I wouldn't trust Feral ports since they don't even recognize the wheel. The issue in this game is obviously a missing profile. About the Windows version under Proton, I'd test more games that have a profile for that wheel and see which axes they use.
And what about using what the wheel reports in its HID descriptors? How does the wheel report the axes? I think this should be what the drivers should be using.
I wouldn't add a module parameter to change mappings. I think it's inconvenient and it's the user software responsability.
How does the wheel report the axes?
It uses Y for the brakes, Z for gas and Slider1 for the clutch. Which is arguably stranger.
I'd test more games that have a profile for that wheel and see which axes they use.
PC2 | rFactor 2 | F1 2018 | F1 2015 | DiRT Rally 2 | DiRT 4 | |
---|---|---|---|---|---|---|
Gas | Z | Z | Rz | Rz | Rz | Rz |
Brake | Rx | Rx | Y | Y | Y | Y |
Clutch | Y | Y | 2 | 2 | Rx | Rx |
F1 and DiRT are both Codemaster series, so I guess it makes sense why they would have similar setups, but PC2 and rFactor 2 are interesting. All results except DiRT 4 were recorded with Proton.
Compared to issue #14 I cannot find a way to solve my problem. Do you have any idea how to make the steering wheel recognizable in FH5? I can show you the folders etc. on Discord, maybe that will help.
@delauflahm Sorry, we got a bit off topic. I'll reiterate:
As for Forza, I'm 90 % sure the issue is with Proton, as protondb has multiple reports of it having issues detecting other input devices. Some claim that using Glorious Eggroll's Proton fork fixes it for them, but if it's too much of a hassle to install I would just wait for Proton to get updated, GE's patches usually get upstreamed fairly quickly.
GE's fork can be found here: https://github.com/GloriousEggroll/proton-ge-custom
Other than that, I currently don't have any other ideas.
Compared to issue #14 I cannot find a way to solve my problem. Do you have any idea how to make the steering wheel recognizable in FH5? I can show you the folders etc. on Discord, maybe that will help.
Since it seems to be a game specific issue, probably due to Proton, I'd enter the conversation at https://github.com/ValveSoftware/Proton/issues/5285
Interestingly, using the default rdesc
mapping Slider1
is problematic. Running under Proton it shows up as Inverse X-axis rotation
, which is probably why Rx
shows up in the table above, maybe a Wine issue? Anycase, what's probably more important is that Slider1
is apparently completely ignored by Feral, so when running DiRT 4 and F1 2015 the clutch pedal isn't recognised at all. When the clutch is mapped to Rx
, things seem to work the best, at least in Codemaster games.
Maybe I'm overthinking this, but I guess it might be best if I stick to the 'typical' mapping and just modify the mapping in game when they're needed. Some games (DiRT 4 cough cough) make it a bit more tedious than it really should be, but I guess I can live with it.
I copied this into the inputdevices.json
file of Dirt4 and it worked fine.
I used Proton-6.21-GE-2.
{
"Name": "Thrustmaster T300 RS",
"VendorID": "0x044f",
"ProductIDs": [
"0xb66e"
],
"Category": "Wheel",
"Type": "ThrustmasterWheel"
},
I found the DefaultWheelMappingProfileThrustmasterT300RS.xml
file.
In /Steam/steamapps/common/ForzaHorizon5/media/ you can find inputmappingprofiles.zip
which contains all .xml
files for the input devices.
Does this help?
Hi, may I please add to this thread with a similar or maybe the same issue? I am running Kubuntu 22.04. I have a brand new T300RS GT and just installed the hid-tmff2 driver and oversteer. In contrary to the descriptions for the T300RS, my GT version does not have a PS3 mode. One can only select PS4/PS5 (switch to the left, red respectively orange LED) or PC (switch to the right, green LED). To my knowledge the basic and GT version have the same wheel base and only different pedals. So the PS3 on the T300RS version should correspond to PC mode on the T300RS GT.
My wheel got delivered with firmware V34 and I found no way to revert it back to V31 in windows 10. Is that an issue?
I currently only have DiRT4 installed in native (but I also have all the other DiRT games available if needed).
I have also added the entry to the DiRT4 inputdevices.json
as mentionned above with ID 0xb66e. But this doesn't help in my case.
When in PC mode: Neither Steam nor DiRT 4 recognize the wheel (but oversteer etc do). lsusb
gives Bus 001 Device 017: ID 044f:b66e ThrustMaster, Inc. Thrustmaster T300RS Racing wheel
.
When in PS4 mode (orange LED) or in When in PS5 mode (red LED): lsusb
spits out the ID b66d. Kubuntu system settings and jstest-gtk recognize it but oversteer doesn't. Steam recognizes it as a standard gamepad and DiRT4 also recognizes it as "Thrustmaster Racing Wheel FFB". I assume DiRT4 only recognizes it through Steam as a standard controller. However I didn't find a way to meaningfully configure key bindings and calibration since Steam/DiRT4 assume it to be a normal controller. Gas pedal has to be kept halfway pressed to even be able to navigate the manues (as mentionned in one of the posts above, probably due to the calibration which gives a value of 32767 when pedals are not pressed, 0 halfway pressed and -32767 when fully pressed)
Any idea where the problem might be? I think the cleanest way would be to get it running in PC mode as that should be the one which is best tested in the driver?
Thanks in advance!
@Blop32 Hello.
My wheel got delivered with firmware V34 and I found no way to revert it back to V31 in windows 10. Is that an issue?
Shouldn't be, see https://github.com/Kimplul/hid-tmff2/issues/41
So the PS3 on the T300RS version should correspond to PC mode on the T300RS GT. ... When in PC mode: Neither Steam nor DiRT 4 recognize the wheel (but oversteer etc do). lsusb gives Bus 001 Device 017: ID 044f:b66e ThrustMaster, Inc. Thrustmaster T300RS Racing wheel.
Apparently you have some newer hardware revision, but the ID that your wheel presents itself in PC mode is the same as older wheels in PS3 mode. This doesn't necessarily mean they are identical, but for now let's assume they are.
I think the cleanest way would be to get it running in PC mode as that should be the one which is best tested in the driver?
That's correct, it is.
Any idea where the problem might be?
Okay, there's a bit to chew through, bear with me.
First of all, did you try Proton? Native is nice and all but mucking about with undocumented config files is sketchy at best.
The stuff about menus sounds very similar to https://github.com/Kimplul/hid-tmff2/issues/38. Maybe not related, but I wonder how the PS5 mode works, as the ID matches with PS4 so it might also be able to receive FFB commands. Could maybe be tacked on to that issue?
Steam not recognizing the wheel is normal, from what I've seen. It's not a generic controller, so steam leaves it alone (I think). lsusb
looks correct, so I'm assuming the driver is being loaded correctly. DiRT 4 native working is not a given, as can be seen, so please try other games as well. DiRT Rally has always worked for me, seems to be less picky.
Thanks a lot! Installed DiRT Rally 2.0 in native and works like a charm! Also changed DiRT4 to proton and now it recognizes the wheel in PC mode. It still scrolls down like mad through the menues as mentionned in the post above. Found an ugly workaround, see my post in #38.
Apparently you have some newer hardware revision, but the ID that your wheel presents itself in PC mode is the same as older wheels in PS3 mode. This doesn't necessarily mean they are identical, but for now let's assume they are.
The T300 RS GT seems to work for now in PC mode but I'll keep looking if I see some inconsistencies and report. Better knowing than assuming ;-) If needed I can deeper to provide info. Just ping me.
Cheers!
Doing some winter cleaning, I think this issue was resolved (for some definition of the word anyway) so I'm closing.
Hello,
I'm using Ubuntu 20.10 and running an Intel Core I5 with an AMD Radeon RX 5600 XT.
With the Bash command "lsusb" it shows me this: Bus 001 Device 006: ID 044f:b66d ThrustMaster, Inc. Thrustmaster Racing Wheel FFB
I just bought the Thrustmaster T300 Alcantara Editon and tried to use it for Forza Horizon 5 with Linux. I plugged everything in and tried to configure it in FH5 - didn't work. So the next step was trying to configure the Steering Wheel in the Steam Settings. It was recognized as a normal/typical GamePad. Configuring the Steering Wheel itself in the Controller Settings was possible but I wasn't able to change anything effectively for using it. Then I noticed that the buttons (including the shifter) were recognized which means I could use them in FH5. The Steering Wheel itself (Rotation Axis) and the Pedals were not usable/I could not bind a function on them. Also, I was not able to use them in steam for navigation inside the menus.
I already installed this Linux Kernel Module but there were some errors:
I don't think those errors are fatal because it installed successfully.
According to this maybe my distro does not load these modules because they're unsigned. I also took a lock at issues #8 and #14 - I was not able to find a solution for this problem.
modprobe shows nothing special:
I can also find the "/lib/modules/5.13.0-22-generic/extra/hid-tmt300rs.ko" file. (it's the same for "sudo modprobe hid-tminit")
For "sudo dmesg -w" this shows up:
I've already had a conversation with berarma.
Thanks