T128P to be added?

[Nighthawk604]

I've gone through your instructions about capturing packets etc.

I'm willing to work onthisbut I'm not sure how to analyze this.

[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 https://github.com/Kimplul/hid-tmff2/issues/64#issuecomment-1553649233 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 https://github.com/Kimplul/hid-tmff2/blob/010c0d986d8d75ff2727d164c8c41b08b33549a9/hid-tmt248.c#L9 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 https://github.com/Kimplul/hid-tmff2/issues/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 🙏

[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.

[Sylv1pons]

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

[ghost-dad]

Hi,

please find the packets captured with wireshark in this linked folder. The files cover wheel initialization (upon plugging in) and all FFB test options from the Thrustmaster driver. I ran all these tests in order without touching the wheel - I'm assuming other Thrustmaster wheels have the exact same software and thus it should be much easier to do a 1:1 comparison?

I'll be happy to help with further steps but I'm really out of my depth here, so first I'd like to ensure gathering and sharing all the necessary data so that it's available whether I'll manage to figure this out or not.

I'll try to get the fedit packages uploaded sometime later this week, but here's a question: do I have to turn the wheel for the effects to register properly? I mean, it would be perfect if I could first get a feel for which effects are working and then run a no-hands recording so that I can upload the fedit file as well and have very clear-cut data on timings and effect values. But then again, I wouldn't be surprised if some scaling with the rotation angle was inherent to how some of the effects are coded.

---

Also, here's a little kicker that may either prove useless or a very convenient shortcut to the packet analysis (someone smarter tell me). Still on my Windows machine, CarX Drift Racing Online identifies the wheel as T248. Everything more or less works, just a bit shittily - the LSB/RSB buttons aren't working and force feedback feels off a lot of the time. So assuming the two models are similar enough the T128 receives readable, but mangled signals, perhaps there's some cheeky shortcut to be had comparing simultaneous signals from the game and the driver?

[Kimplul]

Hello, sorry for the delay, I was on holiday. Thanks a lot for the captures, I had a quick look through them and it does indeed seem like the T128 shares the same USB command set as the T300/T248. For example, packet 359 in 10 - punch.pcapng is the opening packet and the format of other packets seems to match as well.

I can try picking out some important values and set up a skeleton for the T128 in a separate branch with a configuration I think might work, I'll try to get it done by the end of the week at the latest. Some tweaking with wheel in hand will likely be required, though, but we can go into detail about that later.

I'll try to get the fedit packages uploaded sometime later this week, but here's a question: do I have to turn the wheel for the effects to register properly?

That's not necessary. There are some effects that take the rotation into account, but that is done on the wheel and the captures shouldn't be affected (at least assuming the wheels are similar enough, which I think they are).

Also, here's a little kicker that may either prove useless or a very convenient shortcut to the packet analysis (someone smarter tell me). Still on my Windows machine, CarX Drift Racing Online identifies the wheel as T248. Everything more or less works, just a bit shittily - the LSB/RSB buttons aren't working and force feedback feels off a lot of the time.

Hard to tell, the game most likely uses some generic FFB library (like SDL), but might have some internal profiles for different wheels (e.g. some wheel has stronger motors so decrease force strength, stuff like that) and is for some reason conflating the two wheels.

So assuming the two models are similar enough the T128 receives readable, but mangled signals, perhaps there's some cheeky shortcut to be had comparing simultaneous signals from the game and the driver?

Sorry, I don't entirely understand what you're getting at. The game sends FFB effects to the OS (again, likely through a library of some sort), and the OS converts the effects to something the wheel understands through a driver (for example, this one ;). It would definitely be useful to do some (preferably identical) task on Windows and Linux and compare the USB traffic between the two, could maybe expose some bugs but that's on my 'maybe some day' list for now.

[Kimplul]

Right, I added a t128 branch, try it out and see what happens (preferably in a virtual machine to be safe, as always). Remember to update the init submodule, something like git submodule update --remote.

I realized the T128 probably shows up as a T248 in the game because they both seem use the same USB product ID, so this driver will probably also report the T128 as a T248 to start with. That can probably be patched later, for now I'm mostly interested in seeing if magic smoke comes out or something like that.

[doghog125]

Testing on my t128x on the 128 branch, so far, oversteer shows nothing. I will try to play need for speed heat and see if it works. By the way, is it worth noting that "lsusb" shows the t128x as "Thrustmaster, Inc. Thrustmaster T128X GIP Racing Wheel"? (No magic smoke yet though)

[doghog125]

Ok so, the game does not even see there is a wheel connected... I forgot to mention that when I ran this: "git submodule update --remote" it said something along the lines of "not a valid git repository". Am I doing something wrong? Also I installed via DKMS

[doghog125]

Just installed via "make" method, still nothing. "lsmod" doesn't list the driver. I am on arch linux

[ghost-dad]

Hi,

Thanks for all the work! I ended up a little sick (hence the delay), but I'll try to test the new branch once I'm back up, probably this weekend.

[Kimplul]

By the way, is it worth noting that "lsusb" shows the t128x as "Thrustmaster, Inc. Thrustmaster T128X GIP Racing Wheel"?

That's fine, lsusb asks the device "directly" what its name is, even though this driver might treat it as a T248.

I forgot to mention that when I ran this: "git submodule update --remote" it said something along the lines of "not a valid git repository". Am I doing something wrong? Also I installed via DKMS

For testing it's usually best to use the manual installation method, it gives the clearest error messages and is arguably the easiest to grok. But yeah, it sounds like you ran the command outside of the git repository, which won't work, try doing it again in the root of wherever you cloned this repository. Without the updated submodule I wouldn't really trust your reports so far, sorry.

Please attach dmesg output of plugging the wheel in once the driver is correctly installed and loaded, any obvious errors should show up easier that way. Also, post any error messages as-is, preferably in code blocks (i.e. surrounded by three backticks), makes it a lot easier to debug. Goes for any errors in any future or present open source projects you may contribute to :)

Thanks for all the work! I ended up a little sick (hence the delay), but I'll try to test the new branch once I'm back up, probably this weekend.

Cheers, no rush, hope you feel better soon.

[doghog125]

Ok, so once I got the updated submodule, ran make and sudo make install, and plugged my wheel in, dmesg output this:

[   41.700712] usb 1-3: new full-speed USB device number 5 using xhci_hcd
[   42.091797] usb 1-3: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[   42.091806] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   42.091810] usb 1-3: Product: Thrustmaster T128X GIP Racing Wheel
[   42.091814] usb 1-3: Manufacturer: Thrustmaster
[   42.091816] usb 1-3: SerialNumber: 00003C4D1CF6B421

[Kimplul]

Interesting, for some reason it looks like the T128 boots with a different id than I was expecting. I pushed a commit to the submodule that should get us further along, git pull && git submodule update --remote and reinstall the driver. You might have to run sudo rmmod hid-tminit before reinstalling.

[doghog125]

sudo rmmod hid-tminit returns rmmod: ERROR: Module hid_tminit is not currently loaded?

[doghog125]

I used make and sudo make install to install the driver this time, it is unloaded from dkms

[GGTNT]

Hey, is the project still on? I recently bought the T128x steering wheel and would like to help you make it compatible with Linux. How can I help you?

[doghog125]

Not repo owner, but can you try to install the driver? I couldn't make it work

[Kimplul]

Hello, yeah I'd still be interested in getting the T128 working. The situation is more or less the same as described in https://github.com/Kimplul/hid-tmff2/issues/67#issuecomment-1883448819, i.e. right now we need someone with a wheel to try out the t128 branch, report back any error messages in dmesg/wherever, check what works and what doesn't.

[doghog125]

So I tried installing again, and it shows up in lsmod

Module                  Size  Used by
hid_tminit             16384  0
uinput                 20480  0
hid_tmff_new           69632  0

But it never gets used by anything and doesn't show up in oversteer.

Here's dmesg -W output

[ 1859.636442] usb 1-3: new full-speed USB device number 11 using xhci_hcd
[ 1860.027439] usb 1-3: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[ 1860.027446] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1860.027448] usb 1-3: Product: Thrustmaster T128X GIP Racing Wheel
[ 1860.027450] usb 1-3: Manufacturer: Thrustmaster
[ 1860.027452] usb 1-3: SerialNumber: 00003C4D1CF6B421

I'm really confused. I loaded the modules with sudo modprobe hid-tmff-new and sudo modprobe hid-tminit I've never really messed with kernel modules before so I'm a little lost on what to do next? A pointer in the right direction (from anyone) would be very appreciated!

[doghog125]

One more thing, trying to figure this out on my own led me to see that there is no "extras" directory in my kernel modules folder?

[Kimplul]

Here's dmesg -W output

If that's all the output, we might be running into an issue where the T128 doesn't report itself to be a HID device. HID is a system built on top of USB, and Linux doesn't probe HID drivers when a device doesn't report supporting HID. This and hid-tminit are both HID drivers, i.e. you probably have installed everything correctly, but Linux is never actually 'connecting' the driver to the wheel.

There were some talks about converting hid-tminit to a USB driver instead of a HID driver, which might fix this. I'm still not entirely sure if USB drivers are allowed to take over HID devices, but I can try to do the conversion, probably sometime later this week. I'm a bit swamped the next few days at least, sorry for the delay.

I had a quick look at the captures again and frankly, I should've noticed this earlier, my mistake. Good news is that the wheel seems to report itself as a HID device after the initialization, at least.

One more thing, trying to figure this out on my own led me to see that there is no "extras" directory in my kernel modules folder?

Seems like that's been changed without updating docs: https://github.com/torvalds/linux/commit/b74d7bb7ca2412ab37bab782591573b5f265872b

EDIT: Slight correction, the extra dir was replaced with updates in the default kernel config last year, but the in-kernel docs still refer to the default location as extra. Apparently most systems have overridden this default for a while now.

[doghog125]

No problem on the delay! You're doing something great here

[Kimplul]

Hello again. Last week was busier than expected, so I only now got around to sniffing around the USB conversion. The conversion seems to work, I managed to initialize my T300, but there are a couple caveats. Apparently it's not entirely straightforward to take control of a HID device with a USB driver, it seems that by default there are at least a couple drivers with higher 'priority' when it comes to HID devices and I had to manually bind the device to the driver. I'm not sure how feasible this approach is for wheels other than the T128, but I'll play around with modaliases and bindings and see if I can figure something out.

Anycase, I pushed my changes to the usb branch over in https://github.com/Kimplul/hid-tminit/tree/usb, please go clone it and check it out. I renamed the driver from hid-tminit to usb-timit so I don't expect any name clashes, but you might want to remove hid-tminit to be on the safe side. make && sudo make install as before.

[doghog125]

So, the wheel is actually getting data now it appears? It is just spinning over and over again at the moment when I plug it in.

dmesg -W output:

[  326.660738] usb 1-3: USB disconnect, device number 58
[  326.661223] usb-thrustmaster 1-3:1.0: URB to get model id failed with error -2
[  326.920259] usb 1-3: new full-speed USB device number 59 using xhci_hcd
[  327.247722] usb 1-3: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[  327.247730] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  327.247732] usb 1-3: Product: Thrustmaster T128X GIP Racing Wheel
[  327.247735] usb 1-3: Manufacturer: Thrustmaster
[  327.247737] usb 1-3: SerialNumber: 00003C4D1CF6B421
[  327.260464] ahaa what the fuck

[Kimplul]

Cool, some kind of progress. Looks like I forgot to take out a debug message, at least it's kind of fitting as I wasn't expecting that to happen. Looks like the command to query the wheel type doesn't work with the T128 for whatever reason and the wheel keeps resetting itself. I'll look through the USB captures again and try to figure out what we're missing, probably overlooking something obvious.

Technically the T128 shows up as a T128 wheel and not a 'Generic Thrustmaster FFB device', so the query might not even be necessary, but at least it's good to know that the USB conversion might be of some value and could potentially in the future add support for more types of wheels.

[Kimplul]

Hello again, sorry for the repeated long delays. I looked at the captures again and it appears the model query is sent out only after the wheel is initialized, which is kind of interesting. That along with the wheel resetting itself when querying the model in the init driver means that the init mode is apparently more different than I initially thought, which I guess I shouldn't find suprising at this point. Thrustmaster wheels in general are really inconsistent, I guess this is just one more aspect of that inconsistency.

In any case, I realized that the init driver kind of already knows which wheel it's working with by the USB product ID, so I added a quick check to the driver that skips the model query if the USB product ID matches the T128, please check it out and let's see what breaks now. Pull the latest usb branch from https://github.com/Kimplul/hid-tminit/tree/usb.

[doghog125]

New dmesg

[61146.794713] usb 1-3: new full-speed USB device number 18 using xhci_hcd
[61147.163771] usb 1-3: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[61147.163779] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[61147.163783] usb 1-3: Product: Thrustmaster T128X GIP Racing Wheel
[61147.163786] usb 1-3: Manufacturer: Thrustmaster
[61147.163789] usb 1-3: SerialNumber: 00003C4D1CF6B421
[61152.648631] usb-thrustmaster 1-3:1.0: setup data couldn't be sent
[61152.648823] usb 1-3: USB disconnect, device number 18
[61152.649356] usb-thrustmaster 1-3:1.0: URB to change wheel mode seems to have failed, error code -2

[doghog125]

Looks like progress

[Kimplul]

Looks like the wheel also rejects some setup interrupts. Again, first time seeing that behaviour, kind of interesting. I moved the setup interrupts to be after the model check, now the driver should ONLY send out a single change request. In the usb captures there's technically one USB packet before the change request, but it looks like it's some kind of 'alternative' model request packet so for now I'm not sending it. Please check out the newest commit.

[doghog125]

Oh my god you did it. Oversteer reports wheel, no dmesg error, and it can run the force feedback tests!

[doghog125]

Thank you so much I don't have torely on windows for racing anymore if games actually work

[doghog125]

Thank you so much! It works on Assetto Corsa!

[Kimplul]

Force feedback and all?

[doghog125]

So far no issues whatsoever! Just like on windows

[Kimplul]

Sounds promising. Thanks everyone who participated in this thread for your help so far!

I'm going to continue looking into the HID->USB conversion for hid-tminit, there are still the caveats I mentioned earlier that I'd like to iron out. I really don't like the idea of two separate init drivers, one for HID and one for USB wheels. I'm probably going to have to ask for help testing the conversion in the (hopefully) near future as well, so I'm going to keep this issue open a little while longer.

If/when you encounter any problems with the T128 not related to the initialization driver (wonky FFB, games not detecting it, stuff like that), please feel free to open up new issues.

[GGTNT]

Hey, first of all thanks to everyone who took part in the project. I'm glad it worked out for you but I don't understand exactly how you did it 😅. I understand that there are several drivers to install? Would it be possible to make a summary of which drivers need to be installed for the steering wheel to work? And also the drivers only work with native games or also with proton? Thank you in advance for your help and your remarkable work :)

[doghog125]

Hi, here's what you need to do at the moment. First, open the terminal. Then get the t128 branch of hid-tmff2 with the command git clone --recurse-submodules -b t128 https://github.com/Kimplul/hid-tmff2.git. Run make and then sudo make install in the cloned directory (make sure you have all dependencies, it'll tell you if you don't). Now that that is installed, you need the usb branch of hid-tminit. So get the branch by running git clone --recurse-submodules -b usb https://github.com/Kimplul/hid-tminit.git. In the cloned directory again, run make and sudo make install. Now that they are both installed, you need to enable the modules. It's recommended but not required to reboot first. Run sudo modprobe hid-tmff-new then run sudo modprobe usb-tminit and the driver will be ready. You can plug in your wheel and start playing at this point. Hope this helped!

[doghog125]

Oh and also, from my testing PCSX2 (a linux app) works, but also Need for Speed Most Wanted (a windows game) and Assetto Corsa (another windows game). So both work.

[Kimplul]

Well put @doghog125. Just to add, Proton games use the same force feedback subsystem as native games, so both proton and native games should work. I'll also stress that the installation procedure is temporary, eventually I'd like to merge the T128 support into main so installation follows the same procedure for all wheels, consider T128 support very early alpha for now. Of course, issue reports are very much appreciated even in this stage.

[doghog125]

It's a damn good alpha. Thanks so much for this support. You're making racing games on linux so much better with this project!

[GGTNT]

Okay thank you for your answers, it works very well for me but if I have any problems, I'll report them in order to move the project forward :)

[doghog125]

Hi, just have a question. Should the LED lights on the wheel work or is that model specific info?

[Kimplul]

Hello again, apologies for the long delay. I unfortunately wasn't able to figure out a way to make one driver handle both raw USB devices and HID devices, so I've finally thrown in the towel and now I'm experimenting with just having two modules, simple as. The HID driver can still reuse most of the USB driver, so I guess this isn't the end of the world, but still a bit annoying.

Anycase, I've pushed a commit that splits hid-tminit in twine, currently top of usb https://github.com/Kimplul/hid-tminit/commit/031ef062ac01af9f2ff4b41dde9a89e460f8168d, please check that it still works with the T128. Please be careful, I would suggest trying it out in a virtual machine as there's always a slight change that I've forgotten about some detail and the module segfaults or something.

[GGTNT]

Hey, I'm sorry for the time without response. I retested the drivers with your modifications but I have an error now :/

Here is the whole error I got: https://pastebin.com/GFVZ8RD9

Thanks for your work :)