T128P to be added? about hid-tmff2

[ghost-dad]

Hi! I've got the T128X wheel (xbox version) and will take a stab at grabbing the inputs in the coming days. And since I also have a proper Windows machine to plug it in, I think it would be smartest and cleanest to just run the FFB test buttons in the thrustmaster firmware and capture the signal from that.

[Kimplul]

Hello, glad to hear you're interested in this project. Looks like the T128P uses the same (or at least a very similar?) base as the T248, which maybe explains your #64 (comment) findings. I'm guessing the wheel didn't work out of the box with this driver though? Sort of interesting, as the bases at least seem identical I can imagine that there's some flag that's different between the wheels that my driver fails to set or some other small detail like that.

For example, the T248 required some extra initialization packets that the T300 didn't need, could be that the T128 is the same, see

hid-tmff2/hid-tmt248.c

Line 9 in 010c0d9

static const u8 setup_0[64] = { 0x42, 0x01 };

If that's the case, you should probably try to capture the packets that are sent out just after the wheel is plugged in. I don't know for sure what the packets might look like or even do, but the ones linked to above got my wheel working.

Still, it might be a good idea to check that the T248 FFB packets are the same ones used by the T128. Turned out that the T248 used the same format as the T300, so force-effects.txt is what you should compare your packets to.
Below is a semi high level description of what you might have to do. If it's starting to look like your packets are identical to mine, we're likely just missing the initialization packets.

Packet analysis isn't too difficult, mostly just tedious. Essentially what we're interested in finding out is what's the format for USB packets that control FFB effects on the wheel. In wireshark, the data you're mostly interested in is the 'Leftover capture data' field at the end of the packet, which is the actual FFB data that is being sent to the wheel. The rest is related to USB packet handling, metadata and such and generally not interesting to us.

Generally what you want to do is figure out

1. How is an effect uploaded to the wheel?
2. How is an effect modified when already uploaded?
3. How is the playback of an effect started?
4. How is the playback of an effect stopped?
5. How is an effect removed from the wheel?

On the Thrustmaster wheels that I'm familiar with, all effect parameters are packed into one packet. For this, you would mostly have to capture uploading an effect to the wheel, note down how the packet looks, remove the effect and capture uploading the same effect with some parameter tweaked, and try to figure out which bits changed.

Usually an effects already loaded has to be modified one parameter at a time, that is one packet per parameter modification. It might be possible to send multiple parameter modifications in a single packet, but that complicates things a lot and I don't really see it worth the effort.

Effects are first uploaded, and then later started through some start packet. The FFB spec technically speaking has separate functions for stopping and removing an effect from the wheel, but Thrustmaster seems to only implement removing an effect completely, at least when interfaced through fedit. Similarly, this driver just reuploads a stopped effect, although in practice I haven't stumbled on any games that ever 'stop' their effects.

Generally I would recommend using fedit, as it is a GUI program and reasonably easy to use, but if you want to you can of course also try https://github.com/Kimplul/ffbsdl. It's a bit more cumbersome to use, but SDL FFB should be cross-platform and you can pretty reasonably verify that commands feel the same both on Windows and Linux.

For an overview of what a user program expects from a wheel, see https://docs.kernel.org/input/ff.html. Note that the documentation doesn't go into a lot of detail, and there are a number of differences in how Windows and Linux handle FFB, some of which I've run head first into. So just trying to emulate what fedit does on Linux won't necessarily work. Off the top of my head, an effect duration of 0 on Windows means literally zero, i.e. the effect shouldn't be played, whereas on Linux it means the effect should last for an infinite amount of time.

Finally, keep in mind that the direction of an effect scales the effect strength, so a direction of 0 is essentially multiplying the strength by zero. Took me a while to figure that out.

Hope this writeup wasn't too confusing, but if you have any questions, feel free to ask. You can also hit me up on discord or somewhere else if you want to have a call, maybe do a live demonstration or something along those lines.

[Nighthawk604]

Here's what I've learnt today.

When the device starts up it uses endpoint 0 and 2 for configuration and HID setup.

Then endpoint 2 blasts out all the buttons and axis updates through HID messages.

The T128 has 11 axis and I think it was 21 buttons. I'll double check the button count.

Here's what is baffling, America Truck Sim works well but it's a linux client.
Rally 2.0 works well but it's using proton.

But Dirt 4 is a linux client but it has never been able to see the wheel.

Yesterday I captured all the fedit effecfts in separate files so I'll go see how close my device is to your results.

[Nighthawk604]

Wow after going through that data T128P is similiar but nothing identical except the packet with 89 in it.

[Nighthawk604]

I've compiled a list of a bunch of these packets, how do I start applying this to the driver?

I've done quite a bit coding but never worked on a driver like this.

Thanx.. hope your weekend is going well.

[Kimplul]

When the device starts up it uses endpoint 0 and 2 for configuration and HID setup.

Then endpoint 2 blasts out all the buttons and axis updates through HID messages.

The T128 has 11 axis and I think it was 21 buttons. I'll double check the button count.

Sounds like my wheels which is good, nice job.

Here's what is baffling, America Truck Sim works well but it's a linux client.
Rally 2.0 works well but it's using proton.

But Dirt 4 is a linux client but it has never been able to see the wheel.

Just to clarify, by 'works well' do you mean that there's force feedback or just that the buttons show up?
If it's only Dirt 4 where the FFB doesn't work, could be something related to #38 and the actual FFB implemented for the T248 in the driver already works for the T128.

Wow after going through that data T128P is similiar but nothing identical except the packet with 89 in it.

Could you clarify what you mean when you say 'nothing identical'? Obviously the exact values I've presented as examples in force-effects.txt will probably be different to what you've captured (e.g. I got 0x82 0x74 but you got 0xab 0x99 for duration or whatever), but the important part is how each field in the packets is interpreted. Were you able to definitely figure out that some bytes in your packets are used differently from what mine seems to be used for?

I've compiled a list of a bunch of these packets, how do I start applying this to the driver?

Assuming it actually is necessary, frankly your best bet is probably to copy hid-tmt300rs.c to something like hid-tmt128.c (and similarly for hid-tmt300rs.h -> hid-tm128.h) and modify the fields in *_upload_* and so on to suit your wheel. I'd recommend doing it in a virtual machine, as a segfault or similar in the driver will probably crash your computer otherwise. Try just getting a simple case working, for example uploading just a constant force without effect parameters or something and go from there.

[doghog125]

Any progress made on this?

[Sylv1pons]

Please can you integrate a linux driver for the T128 steering wheel ?
I can't wait for use this with Batocera V39 🙏

[Sylv1pons]

Thanks for your involvement.
Please keep us informed of ypur progress.
Thank you