Thrustmaster TS-PC (TS Racer) support about hid-tmff2

[solarisfire]

I am going to try and get the USB traces for this... just struggling to find some free time to do it!

[Kimplul]

@Potajito thanks for showing interest. As far as I'm aware, no USB packet captures have been made, so the general outline in #65 (comment) still applies. Please read through https://github.com/Kimplul/hid-tmff2/wiki#how-to-add-in-support-for-a-new-t-series-wheel and if you feel up for, try doing some captured and seeing if you can find some patterns in the data.

[solarisfire]

Could do with some guidance when capturing.

It just seems to be a stream of URB_INTERRUPT and URB_CONTROL packets.

It did come back with some data on unplug/replug but not sure which bits would be the initialization value.

DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: 0x01 (DEVICE)
bcdUSB: 0x0100
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 8
idVendor: ThrustMaster, Inc. (0x044f)
idProduct: Unknown (0xb65d)
bcdDevice: 0x0700
iManufacturer: 1
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1

https://drive.google.com/file/d/13odXGOEfqU_Wfi7NfChZVsW5YsEGFQTp/view?usp=share_link

Not sure where I'd start trying to work out any sort of values for force feedback values. I think I need to find a tutorial for FEdit1...

[Kimplul]

Any chance this wheelbase could be supported?

Supported, probably yes, but how much work that would take is hard to say. Unfortunately thrustmaster wheels
don't seem to really follow any consistent APIs, so two seemingly similar wheels may require wildly different implementations.

Did you already read https://github.com/Kimplul/hid-tmff2/wiki#how-to-add-in-support-for-a-new-t-series-wheel?
In addition to the stuff in the wiki, it seems that the TS-PC's initialization value is unknown, so we'd need some USB packet
captures of plugging the wheel in as well. The value would have to be added to the wheel table in hid-tminit.

[Potajito]

I also have a TS-PC would love to give a hand.

[Kimplul]

Sure, thanks for the capture. Just to start off with, the initial wheel state is with idProduct 0xb65d, and the Windows driver then sends out a packet to restart the wheel. After the restart, the wheel reconnects with idProduct 0xb689, as can be seen at packet no. 156 in your capture. So there should be at least one URB_CONTROL out from host to 3.1.0 in the first 150 or so packets that approximately matches
https://github.com/scarburato/hid-tminit/blob/9375f6c7d83af5dd6c8b8fe30351d0f36043b20a/hid-tminit.c#L140

In this case, it seems to be packet number 151, and from this we can see that the wValue used is 0x0009. This is the switch_value in struct tm_wheel_info.

Then we need to find another packet with the wheel's IDs. The wheel sends a packet to the computer, which should contain a number of bytes, two of which we're mainly interested in: one for the base model and one for the steering wheel attachment. These correspond to model and attachment in struct tm_wheel_info. This data should be found in a packet with bRequest == 73.
There are actually multiple of these packets for some reason (I'm guessing the Windows driver queries different parameters from different parts of the codebase, and it doesn't cache these parameters anywhere so it just requests them multiple times).

Anycase, looking at the data in packet 68, we see that the response data is 49 00 03 04 01 00 09 06 f9 01 00 00 09 01 00 00. This more or less looks like the other captures (some examples can be seen in the README in hid-tminit). Bytes 6 and 7 should be the attachment and model, respectively, so in this case model = 0x06 and attachment = 0x09. Adding an element to tm_wheel_infos[] should get hid-tminit to initialize wheel properly, something like

[...]
{0x06, 0x09, 0x0009, "Thrustmaster TS-PC"},
[...]

With my T300, for some reason I also had to send out a number of other packets, see
https://github.com/scarburato/hid-tminit/blob/9375f6c7d83af5dd6c8b8fe30351d0f36043b20a/hid-tminit.c#L26,

but other wheels don't seem to require this so I would expect that the TS-PC doesn't either.

Not sure where I'd start trying to work out any sort of values for force feedback values. I think I need to find a tutorial for FEdit1...

If you find one, let me know, not aware of any. Probably the biggest individual hurdle is the fact that you have to set the direction of the effect, the default of 'straight up' effectively translates to multiplying the force's magnitude by 0, i.e. makes the effect impossible to detect. Try dragging the direction pointer all the way to the right for example, and then go from there. Maybe go for studying just one effect at a time, i.e. press the effect button and drag it to the timeline. Note that the location on the timeline effectively adds a delay, i.e. to immediately feel an effect drag it as far left as possible.

Other than that, I guess it's worth keeping in mind that wheels typically have a couple different kinds of packets, ones that upload effects to the device and ones that modify already uploaded effects. Took me a while to figure that one out, but essentially when close the effect modification window, you should see the effect get uploaded with all possible configuration values initialized. After that, if you open up the modification window again and tweak one parameter, you should see a number of packets that each modify only the parameter you've just tweaked. If the packets you capture look like ones in https://github.com/Kimplul/hid-tmff2/blob/master/docs/FFBEFFECTS.md,

then it should be fairly straightforward to just add the wheel's USB product ID to the list of supported devices for this driver. Otherwise, you'll have to try and reverse engineer the packets yourself.

I encourage playing around with FEdit, it's ultimately not a particularly complicated program, as it more or less one-to-one maps parameters in the GUI to parameters that get sent to the wheel. The interface is just a bit daunting.

Feel free to ask questions, I'll try to help as best as I can.