T500 RS support

[cazzoo]

Hi there,

Good work so far to get T300 RS support to linux; Kudos!
I wonder if you can bring T500 RS support to your project.
I know there are some other alternatives that started to make the device detection working (https://github.com/her001/tmdrv) so maybe there something to combine with you two projects.
Personally owner of T500 RS + shifter, I'd be glad to give some help if I can anyhow, but I don't know from where to start...

[Kimplul]

Heyo, first of all, thanks bud. Second, I'm aware of tmdrv, and I actually posted a notice about my project on the project's gitlab page a while ago. @scarburato wrote a more generic init driver based on the information found by the tmdrv project.

That being said, device detection is just a part of the GNU operating system getting the wheels to work properly in games. I'm guessing your first assumption was that since the wheels are from the same manufacturer and same series, they should behave similarly. That was my initial assumption as well, which is why I named this project hid-tmff2 instead of hid-tmt300rs or something similar. Well, you might be right, I have no data on the T500 RS, but the T300 RS and the T150 are drastically different, unfortunately, and I wouldn't be surprised if it's the same thing with T300/500. You can compare @scarburato's T150 driver and this one.

The easiest way to figure out if the T500 works the same as the T300 might be to just change 0xb66e on the line

hid-tmff2/hid-tmt300rs.c

Line 1599 in cf31a8e

{HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb66e),

to whichever product ID the T500 RS has, and see if the driver still works. If it does, great, if it doesn't, more drastic measure must be taken. If you decide to try this out, I recommend doing it in a virtual machine to make sure nothing of value is lost if the driver decides to crash on you. Shouldn't, but you never know.

Getting the correct value to place instead of 0xb66e should be as easy as running lsusb with the T500 RS detected (i.e. the name of the device is something like T500 RS Racing wheel instead of Generic Thrustmaster FFB Wheel) and looking at 044f:abcd, where abcd should be the product ID in hex.

If the simple change I presented doesn't work, which I sort of doubt, you'll probably have to do a lot of reverse engineering. I did it by installing fedit(sorry for the sketchy link, it was the only one I could find) on a Windows virtual machine, and capturing the USB traffic between fedit and the wheel when playing a certain effect. Then I just tuned the attributes of different effects, wrote down which bytes in the traffic changed between runs and compiled my educated guesses into force-effects.txt in this repo. I'm still not sure what some of the values are used for, as you can probably see. It's not too complicated once you get the setup out of the way, but it is somewhat tedious and slow.

If this doesn't sound too appealing, I don't blame you. I've been looking into getting a T500 myself and trying to get it to work, but haven't actually gone through with anything yet. And it's not as if this driver is perfect either, see other open issues.

About the shifter, not really sure what to point you towards, as it's somewhat out of my expertise. For a start I guess I would check if it works just by playing around with settings in games. I think I remember figuring out that shifters more or less work by just sending out a button pressed signal when the lever is put in gear, and sending a release event when put out of gear. This might not need a lot of driver logic to do, but if it turns out that the shifter does need a driver, it might be doable with a userland driver. Don't quote me on anything at this point, though.

Feel free to contact me if you have any questions or suggestions, I'll try to address them as soon as possible.

[cazzoo]

Thank you very much for the detailed walk through.
I successfully got the things done (able to capture usb traffic though window VM, installed also your tool) but currently stopped here.
In the meantime I've been forking your repo (and oversteer repo as well) to add T500RS detection on both of them and will continue proceeding with the detection. I just duplicated your classes and updated the device ID hex. Basically no changes so far.

I didn't tested the wheel itself in game yet but I can feel force being applied to the wheel already while steady, probably center position force...
I will keep you posted about my progression.

[Kimplul]

Wonderful, good luck.

[tgurr]

I've tried the modified driver from @cazzoo. The wheel seems to be initialized correctly as far as I can tell.

$ lsusb | grep Thrust
Bus 003 Device 007: ID 044f:b65e ThrustMaster, Inc. TRS Racing wheel

dmesg output:

[ 4022.522023] usb 3-6.2: new full-speed USB device number 6 using xhci_hcd
[ 4022.619386] usb 3-6.2: New USB device found, idVendor=044f, idProduct=b65d, bcdDevice= 1.00
[ 4022.619395] usb 3-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4022.619397] usb 3-6.2: Product: Thrustmaster FFB Wheel
[ 4022.619399] usb 3-6.2: Manufacturer: Thrustmaster
[ 4022.696636] input: Thrustmaster Thrustmaster FFB Wheel as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.3/usb3/3-6/3-6.2/3-6.2:1.0/0003:044F:B65D.0009/input/input21
[ 4022.696781] hid-tminit 0003:044F:B65D.0009: input,hidraw6: USB HID v1.00 Gamepad [Thrustmaster Thrustmaster FFB Wheel] on usb-0000:2a:00.3-6.2/input0
[ 4022.718935] hid-tminit 0003:044F:B65D.0009: Wheel with model id 0x2 is a Thrustmaster T500RS
[ 4022.722987] hid-tminit 0003:044F:B65D.0009: Success?! The wheel should have been initialized!
[ 4022.913804] usb 3-6.2: USB disconnect, device number 6
[ 4023.116567] usb 3-6.2: new full-speed USB device number 7 using xhci_hcd
[ 4023.216916] usb 3-6.2: New USB device found, idVendor=044f, idProduct=b65e, bcdDevice= 1.00
[ 4023.216921] usb 3-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4023.216924] usb 3-6.2: Product: TRS Racing wheel
[ 4023.216926] usb 3-6.2: Manufacturer: Thrustmaster
[ 4023.304140] input: Thrustmaster TRS Racing wheel as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.3/usb3/3-6/3-6.2/3-6.2:1.0/0003:044F:B65E.000A/input/input22
[ 4023.304231] t500rs 0003:044F:B65E.000A: input,hidraw6: USB HID v1.11 Joystick [Thrustmaster TRS Racing wheel] on usb-0000:2a:00.3-6.2/input0
[ 4023.306924] t500rs 0003:044F:B65E.000A: force feedback for t500rs

$ ls -la /dev/input/by-id/ | grep Thrust
lrwxrwxrwx 1 root root  10 30. Mai 19:03 usb-Thrustmaster_TRS_Racing_wheel-event-joystick -> ../event17
lrwxrwxrwx 1 root root   6 30. Mai 19:03 usb-Thrustmaster_TRS_Racing_wheel-joystick -> ../js0

$ ls -la /sys/bus/hid/devices/0003\:044F\:B65E.000A/
insgesamt 0
drwxr-xr-x 5 root root    0 30. Mai 19:03 .
drwxr-xr-x 6 root root    0 30. Mai 19:03 ..
-r--r--r-- 1 root root 4096 30. Mai 19:10 country
-rw-r--r-- 1 root root 4096 30. Mai 19:10 damper_level
lrwxrwxrwx 1 root root    0 30. Mai 19:03 driver -> ../../../../../../../../../../../bus/hid/drivers/t500rs
-rw-r--r-- 1 root root 4096 30. Mai 19:10 friction_level
drwxr-xr-x 3 root root    0 30. Mai 19:03 hidraw
drwxr-xr-x 3 root root    0 30. Mai 19:03 input
-r--r--r-- 1 root root 4096 30. Mai 19:10 modalias
drwxr-xr-x 2 root root    0 30. Mai 19:10 power
-rw-r--r-- 1 root root 4096 30. Mai 19:10 range
-r--r--r-- 1 root root 4096 30. Mai 19:03 report_descriptor
-rw-r--r-- 1 root root 4096 30. Mai 19:10 spring_level
lrwxrwxrwx 1 root root    0 30. Mai 19:03 subsystem -> ../../../../../../../../../../../bus/hid
-rw-r--r-- 1 root root 4096 30. Mai 19:03 uevent

Trying the native Dirt Rally version on Steam the wheel and the pedals seems to work as far as it reacts to steering the wheel, pressing the pedals, buttons, etc. However the wheels is stuck in the center position and FF doesn't seem to work so it's not playable/usable right now since the steering wheel is constantly pushing into the center position.

Trying the same on Windows the "lock" to the center position is released as soon as the level loads.

oversteer is segfaulting on my system but I guess that's unrelated as it also does when the wheel is not plugged in. Trying https://github.com/berarma/ffbtools I also couldn't apply any FF to the wheel.

[ 4023.304140] input: Thrustmaster TRS Racing wheel as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.3/usb3/3-6/3-6.2/3-6.2:1.0/0003:044F:B65E.000A/input/input22

$ cat /sys/bus/hid/devices/0003\:044F\:B65E.000A/input/input22/capabilities/ff
31fff0000 0

seems to report no FF capabilities(?).

fftest (https://sourceforge.net/projects/linuxconsole/) as mentioned at https://www.kernel.org/doc/html/v5.12/input/ff.html also does nothing:

$ ./fftest /dev/input/event17
Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/event17 opened
Features:
  * Absolute axes: X, Y, Z, RZ, Hat 0 X, Hat 0 Y, 
    [27 00 03 00 00 00 00 00 ]
  * Relative axes: 
    [00 00 ]
  * Force feedback effects types: Constant, Periodic, Ramp, Spring, Friction, Damper, Rumble, Inertia, Gain, Autocenter, 
    Force feedback periodic effects: Square, Triangle, Sine, Saw up, Saw down, 
    [00 00 00 00 00 00 00 00 00 00 FF 1F 03 00 00 00 ]
  * Number of simultaneous effects: 16

Setting master gain to 75% ... OK
Uploading effect #0 (Periodic sinusoidal) ... OK (id 0)
Uploading effect #1 (Constant) ... OK (id 1)
Uploading effect #2 (Spring) ... OK (id 2)
Uploading effect #3 (Damper) ... OK (id 3)
Uploading effect #4 (Strong rumble, with heavy motor) ... OK (id 4)
Uploading effect #5 (Weak rumble, with light motor) ... OK (id 5)
Enter effect number, -1 to exit
0
Now Playing: Sine vibration

Please let me know if there's anything I can do to help, looks things are nearly there but not quite yet.

Additional note: I've also submitted a PR to add the wheel under the initialized ID to SDL: libsdl-org/SDL#4404

[Kimplul]

Heyo, thanks for taking an interest in this/@cazzooo's project.

fftest seems to claim that all effects are being reported, but sounds like the USB API the T500 RS uses is different from the T300RS, leading to no FF. Sort of what I was afraid of, unfortunately. Could also be that the wheel has to be 'initialized' for FF mode, which in my driver is done when opening the device. Look at sections open and close in force-effects.txt and t300rs_open and t300rs_close in hid-tmt300rs.c.

Anycase, to figure out what the API differences are, you would probably have to do the process I outlined earlier in this thread. I don't know how far @cazzoo has gotten with his work, but you could always try to communicate with him about what needs to be done. You can do it in this thread if you'd like, but if you come up with some better platform that's fine as well.

Other than that, just using and testing the driver is of great help. For example, #6 shows some issues I probably would've never found out about on my own, since apparently different T300 wheels work slightly differently, and I wouldn't be surprised if it's the same story with the T500.

Thanks for opening the SDL PR, I still haven't confirmed if it fixes FF in some games but I can't hurt.

[tgurr]

I hope @cazzoo is more competent than me to figure this out, I gave it a quick spin on Windows by installing wireshark which supports usb capture nowadays as well, but after having it installed fedit didn't work anymore at all, no matter what command I sent, the wheel didn't do anything anymore. And even then I would have probably have failed on how to isolate the correct USB traffic since fedit seems to provide many options/values for the individual commands and even switching active windows between wireshark and fedit made some usb traffic being logged. So I would probably need help by explaining everything step-by-step for starters. Though I'm very interested to get things working as Linux is my main OS also for gaming and the wheel has been sitting there unused for years already but it would be nice to not also have it working for hardcore fast racing games, but for rather slow ones like e.g. the new snow runner and the truck simulators whiich would probably better fit my gaming habits these days and probably also wouldn't require everything to run 100% accurate.

[cazzoo]

Hi @tgurr, thank you for interest in this project. Help will be greatly appreciated.
So far I didn't work much on the data analysis, but I successfully captured some packets with wireshark through VM.
I think I may worth combining efforts. So far, with the current analysis ran from pack capture, I could figure that packet structure is not the same for T500RS as it is for T300RS (except if I'm totally wrong; this is possible since I'm brand new in hardware Reverse Engineering).
I suggest that we may encounter on discord or such. I'd be glad to help you setting your environment up so you can start playing with RE. Also, I can grant you access to my repo if you would like to contribute.
As of you, I'm really eager to get something working for this wheel on Linux. Let me know

[cazzoo]

@tgurr I've added some hex dumps for convenience but I didn't succeed getting this parsed in the driver yet.
Let me know if you have time to spend with me so we can make work together to decode the buffer data

[cazzoo]

Hi both,
I discovered a new way to extract data from wheel usage as described here : gimx force feedback capture.
I did capture API calls with success but unfortunately I cannot do anything from them already.
I can share the T500RS capture files (both API monitor and wireshark) for analysis but @Kimplul if that talks a bit much to you I'd be pleased to get into it together with you.

[Kimplul]

Sure, if you already set up a Discord server send me a link, I'd be happy to join in.

I took a cursory glance at the data you've put up on your repo, and seems like you might unfortunately have to modify a bit more code than maybe initially though. I got lucky enough that the T300RS uses HID requests, so each packet is the same size. The T500RS, form the looks of it, has different length packets, but hid_hw_request only sends out packets whose size is defined by the rdesc of the device, so we might have to find some other communication method. Something like what I used earlier might work, see https://github.com/cazzoo/hid-tmff2/blob/ef17e70ffe6f350679c635f74cd9a4e75c47193c/hid-tmt300rs.c#L48-L57

[cazzoo]

Hi @Kimplul,
you can join https://discord.gg/wHSMdnWU channel. This is mainly a French server we used with my Racing mates but feel free to join. Once online we can surely share a voice talk or something alike.
I didn't have much time yet to spend on it but I'm really eager to understand and make it working :)

[hoover67]

Hi folks,

also a Linux using t500rs owner here. I'm glad to see some efforts are undertaken to get this device working on Linux and I'd be happy to help with testing anything that comes up.

All the best, Uwe

[ghost]

I am interested also, and would be happy if I can provide anything useful :)

[Kimplul]

Hello again, the T500 effort's been pretty quiet for a while. This bump is to call for volunteers to help reverse engineer the T500 RS USB api.

The current state of the T500 effort is over at https://github.com/cazzoo/hid-tmff2. There are some initial USB packet captures and rdesc info, but more captures would be needed. These captures will need to interpreted, which is likely where the bulk of the work is, and eventually implemented and tested in the driver.

If you own a T500 and would be interested in helping us out, please have look through the wiki for how to capture packets and go about reverse-engineering them. Feel free to ask for help, I'll try to assist as well as I can.

[ghost]

Hi,

I'm glad to hear that you're working on reverse engineering the USB API of the T500 RS. I have a T500 and I have a dual boot with Windows and Debian on my machine. Additionally, I have the ability to run Windows within a QEMU virtual machine. I would be happy to assist you in your efforts, but I would need some explanations on how I can contribute. Could you please explain to me how I can help?

Thank you very much!

[Kimplul]

Hello @MonsorP4py, thanks for showing interest. A short overview of what has to be done can be found in the wiki:

https://github.com/Kimplul/hid-tmff2/wiki#how-to-add-in-support-for-a-new-t-series-wheel

TL;DR: We're mainly interested in the USB packet format, i.e. when a user requests a force feedback effect, what would the corresponding USB packet look like. You don't necessarily have to know how to program in C or Linux internals, I'll try and help with that as much as possible.

A fairly good first milestone would maybe be figuring out the constant force. It's arguably the simplest and most widely used, so even with just it implemented we might already have a decently usable driver. Note that uploading an effect is done in one packet where all parameters are passed at the same time, but modifying effects is done with one parameter per packet.

What's so far been uncovered can be found over in https://github.com/cazzoo/hid-tmff2

Please feel free to ask about details and specifics.

[silverlore]

Hello @Kimplul I have tried to make a wireshark capture for constant force. I got 4 packages I have uploaded them to https://github.com/silverlore/hid-tmff2/blob/const_force/captures/device_const_force_pos.pcapng.

Can you help me prepare the capture for merge with cazzoo's branch?

[Kimplul]

Hello, looks like you've successfully captured starting and stopping an effect. The leftover capture data looks to be identical to START and STOP in force-effects-t500.txt. Note that the packets with source 9.11.1 are packets that the device sends back after receiving the FFB commands, and we're generally not that interested in them. They're mostly just a confirmation that the device received and processed the packet correctly.

Can you help me prepare the capture for merge with cazzoo's branch?

Sure, what would you need help with?

Note, I'm not sure how useful one capture on its own is. There's a list of some already made hex dumps in T500 hex dump.txt, you can do some more captures and see if you can replicate them. Eventually maybe adding missing stuff and periodic effects to the list could be useful.

[silverlore]

The help I need was if something were missing or to many data. I will try to reproduce some of the T500 hex dump.

This is my first time capturing data like this so I am a little unsure if I am doing it right.

[Kimplul]

The help I need was if something were missing or to many data.

Right, gotcha. You could argue that there's sort of both too little and too much. As previously stated, half of the packets are kind of unnecessary, but they don't really hurt anything and in these kinds of things it's usually better to add in a bit too much extra stuff than to leave out some bit that turns out to be important. Conversely, starting and stopping is largely already figured out, and we'd really need the packets that handle constant force feedback specifically, but at least we have confirmation that you're capturing more signal than noise.

Keep in mind that the packet that uploads the force to the wheel is sent out when you add the effect, not when you start playing the effect. Also, you can edit an effect while it's playing to get the modification packets.

This is my first time capturing data like this so I am a little unsure if I am doing it right.

First time for everything. Don't worry, looks like you're on the right track. Play around with the captures a bit, I'm sure you'll get the hang of it.