No FFB for Thrustmaster T300

[creeper82]

I have been using my wheel once in a blue moon with this driver, and it always had worked (maybe with a few quirks in some games but no big deal). Coming back after a longer break, I just can't get the FFB to work again. I feel like I have tried everything, so I gave up and started seeking for help here. I don't even know if an update caused it, or was it some mistake of mine

So the wheel works great. All the buttons, pedals - everything is registered. The Oversteer app detects the wheel, and I can adjust various settings, including auto-center strength. The only thing that does not work is the force feedback. I can't even get it to work in fftest. When I run any test, the wheel is simply silent, doesn't move an inch

I have tried both PlayStation and PC modes, multiple USB ports, etc. here is the dmesg output, I suppose it looks ok?

[   55.436643] usb 5-1: new full-speed USB device number 3 using xhci_hcd
[   55.578903] usb 5-1: New USB device found, idVendor=044f, idProduct=b65d, bcdDevice= 1.00
[   55.578919] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   55.578926] usb 5-1: Product: Thrustmaster FFB Wheel
[   55.578933] usb 5-1: Manufacturer: Thrustmaster
[   55.755446] input: Thrustmaster Thrustmaster FFB Wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.4/usb5/5-1/5-1:1.0/0003:044F:B65D.0006/input/input28
[   55.755851] hid-thrustmaster 0003:044F:B65D.0006: input,hidraw5: USB HID v1.00 Gamepad [Thrustmaster Thrustmaster FFB Wheel] on usb-0000:06:00.4-1/input0
[   55.776683] usbhid 5-1:1.0: Wheel with (model, attachment) = (0x2, 0x6) is a Thrustmaster T300RS. attachment_found=1
[   55.777826] usb 5-1: USB disconnect, device number 3
[   55.778809] usbhid 5-1:1.0: URB to change wheel mode seems to have failed, error code -2
[   56.395680] usb 5-1: new full-speed USB device number 4 using xhci_hcd
[   56.542939] usb 5-1: New USB device found, idVendor=044f, idProduct=b66e, bcdDevice= 1.00
[   56.542954] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   56.542961] usb 5-1: Product: Thrustmaster T300RS Racing wheel
[   56.542967] usb 5-1: Manufacturer: Thrustmaster
[   56.642664] input: Thrustmaster Thrustmaster T300RS Racing wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.4/usb5/5-1/5-1:1.0/0003:044F:B66E.0007/input/input29
[   56.643131] hid-generic 0003:044F:B66E.0007: input,hidraw5: USB HID v1.11 Joystick [Thrustmaster Thrustmaster T300RS Racing wheel] on usb-0000:06:00.4-1/input0
[   57.012083] input: Thrustmaster Thrustmaster T300RS Racing wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.4/usb5/5-1/5-1:1.0/0003:044F:B66E.0007/input/input30
[   57.012277] tmff2 0003:044F:B66E.0007: input,hidraw5: USB HID v1.11 Joystick [Thrustmaster Thrustmaster T300RS Racing wheel] on usb-0000:06:00.4-1/input0
[   57.014666] tmff2 0003:044F:B66E.0007: force feedback for T300RS

I don't expect anyone to reply during this wonderful new year period, but I'd love to enjoy some games without having to resort back to Windows. At this point I am looking for some direction, how to even debug this?

Edit: I just realized that I have posted an issue a year ago. Back then, it went away on it's own, but this time I can't fix it

Edit2: just plugged in to a windows computer. The firmware is newest and FFB works on windows

[Kimplul]

here is the dmesg output, I suppose it looks ok?

Yep, looks good to me. Oversteer handling the wheel is also a good sign.

I can't even get it to work in fftest

Could you include the exact command you're using, preferably also including the command output? fftest might not by default open up the right device, and generally needs correct path to be specified by the user, so I'd like to sanity check this to start with.

[creeper82]

Yes, I chose the right one (in my case event24). Out of curiosity I've also downloaded some other tool (ffbtools) and it doesn't have any effect on the wheel either. Tried with various games, some through steam, some through wine, no luck. Any ideas? I wouldn't be surprised if it ends up being something simple

[Kimplul]

Yes, I chose the right one (in my case event24)

It's probably preferable to use the symbolic name, something like fftest /dev/input/by-id/usb-Thrustmaster-*-event-joystick, please just post it and the output so I can check for myself.

Any ideas?

Not at the moment, no. If fftest is not working, it would likely indicate something between the driver and the wheel itself, as there's not a lot that can go wrong between fftest and the driver itself. Since Windows seems to be working, it's likely not a hardware issue, but might be a newer firmware version that is incompatible with the one(s) that this driver was developed against.

Otherwise, could be an update to the SDL layers, some new handling of FFB flags or something. If you're still on Arch, you might be receiving updates faster than people on other distros and we might be getting more reports coming in over the coming months. No clue what happened in your last issue (this one, right? #134) when the wheel apparently started working by itself , the same issue could be re-appering.

[creeper82]

Here is the output. I can't feel anything on the steering wheel. As for the last issue, I can't remember at all. It was totally random, but back then I remember fftest would produce the force feedbacks on some random occasion. Now it never happens

fftest /dev/input/by-id/usb-Thrustmaster_Thrustmaster_T300RS_Racing_wheel-event-joystick 
Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/by-id/usb-Thrustmaster_Thrustmaster_T300RS_Racing_wheel-event-joystick 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 1)
Uploading effect #1 (Constant) ... OK (id 2)
Uploading effect #2 (Spring) ... OK (id 3)
Uploading effect #3 (Damper) ... OK (id 4)
Uploading effect #4 (Strong rumble, with heavy motor) ... OK (id 5)
Uploading effect #5 (Weak rumble, with light motor) ... OK (id 6)
Enter effect number, -1 to exit
0
Now Playing: Sine vibration
Enter effect number, -1 to exit

[Kimplul]

Thanks! fftest looks good, all effects are reported as they should, which would indicate something on the kernel side.
Off the top of my head, some things that may or may not be worth checking:

• Just a sanity check, are all gain settings in Oversteer set to non-zero?
• What firmware version is the wheel at? 34 is what I've had on my wheel, IIRC.
• Can you try out older versions of this driver? Commits around a year ago might be a good starting point. No particularly significant changes have been made in the codebase this year so I would expect the older versions to not work either, but I have been wrong before.

[creeper82]

1. Yes, they're non-zero
2. Exactly - 34

I guess I'll try out some older commits. What's the quickest way to install them? Do the manual installation everytime after checking out to a commit? Do I have to uninstall the current one somehow? At this moment, I have the current tmff2 installed manually, with make, no DKMS (but I've tried dkms too in terms of the issue). Thanks a lot for the unexpectedly fast replies

[Kimplul]

I guess I'll try out some older commits. What's the quickest way to install them? Do the manual installation everytime after checking out to a commit? Do I have to uninstall the current one somehow?

DKMS you will have to uninstall, sudo dkms remove --all hid-tmff2/0.82, but after that each manual sudo make install will overwrite the previous sudo make install. Although you'll also want to run sudo rmmod hid-tmff-new && sudo modprobe hid-tmff-new after each install to unload the previous version from the kernel and make sure the newly installed one is used.

Git also has a built-in tool, git bisect, which you may want to play around with. It automates the process of picking which commit to check when you have a known good and a known bad commit, may or may not save time in this case.

Thanks a lot for the unexpectedly fast replies

No worries, my new year's plans got cancelled so I don't currently have anything better to do :)

[creeper82]

I thought I was gonna use the bisection to pinpoint a breaking change commit, but I can't even find a working commit now. I tried the ones from 2024 (back then, everything worked well for me) but to no avail (compiles well, but no FFB - exact symptoms as with the newest version). I can't go too much into the past as there is a make error:

  CC [M]  src/hid-tmff2.o
src/hid-tmff2.c:740:25: error: initialization of ‘const __u8 * (*)(struct hid_device *, __u8 *, unsigned int *)’ {aka ‘const unsigned char * (*)(struct hid_device *, unsigned char *, unsigned int *)’} from incompatible pointer type ‘__u8 * (*)(struct hid_device *, __u8 *, unsigned int *)’ {aka ‘unsigned char * (*)(struct hid_device *, unsigned char *, unsigned int *)’} [-Wincompatible-pointer-types]
  740 |         .report_fixup = tmff2_report_fixup,

according to chat gpt it is due to some API change in newer kernel versions

The only thing that I'm not sure of is the exact hot-swap procedure when installing another version. I do make clean, then install it like usual, then rmmod and modprobe, all while looking at dmesg output. No errors, it always shows the tmff2 message that FFB is active. Again, I tried fftest, and similar tools, native games, Proton windows games - the wheel is always detected, buttons and axis works except FFB itself. So that's the same story as on the newest driver version

Just to be extra sure I rebooted a couple of times after doing the install, tried booting up with and without the wheel already plugged in, still nothing..

If you have time and will, I'm open to any further suggestions/debugging, but I also guess that it might be something basically impossible to detect at this point. Maybe it's caused by having all the newest packages (Arch). I really wonder what's the deal, especially since it's such a silent failure that everything looks good on paper. I can't find a trace of any error or warning in all kinds of outputs. And since changing the version of your driver doesn't help, it could even be completely unrelated. If only I hadn't set up so many things now, I would have reinstalled the whole OS, but that's the last resort if anything

[creeper82]

Tomorrow I'm going to fire up the Linux LTS kernel, to check if the kernel changes didn't cause the issues. At least given that the nvidia drivers won't complain about the change

[Kimplul]

according to chat gpt it is due to some API change in newer kernel versions

Yep, here's the PR with the change: #128 A bit older than a year so commits older than that would be older than the version that worked for you, and presumably wouldn't be particularly revealing anyway.

I guess the next lower level of debugging would be to fire up Wireshark and try to see if the driver is sending out packets to the wheel. If the driver is sending out packets but the wheel isn't responding, then it's something with the wheel itself (driver isn't setting the wheel up properly, wheel is getting huffy about the way packets are sent like in #6, something along those lines). If no packets are being sent out, there's likely bug in the driver that you're running into that I'm not aware of. See the Wiki entry at https://github.com/Kimplul/hid-tmff2/wiki#how-to-capture-what-usb-packets-the-driver-sends-to-the-device to start with, but feel free to ask for clarification as well.

Alternatively, a slightly less cumbersome way to check roughly the same thing as above could be to add something like hid_error(t300rs->hdev, "sent packet"); to

hid-tmff2/src/tmt300rs/hid-tmt300rs.c

Line 457 in 2699542

int t300rs_send_buf(struct t300rs_device_entry *t300rs, u8 *send_buffer, size_t len)

which should fill dmesg with messages whenever the driver 'thinks' it has sent out a packet. hid_error so that the messages are sure to show up in dmesg, hid_info or hid_dbg could also be appropriate but would require setting the kernel log levels appropriately. I would assume that "the driver 'thinks' it has sent out a packet" is the same as "a packet shows up in Wireshark", but I have been wrong before.

[creeper82]

I tested both the program -> driver, and driver -> wheel connections

program -> driver

I wrapped fftest in ffbwrap. Jugding by the game log, it works (well, as expected from something as simple as fftest). And the numbers seem ok? I'm only not sure what are the 24 responses but I guess it's nothing special.

driver -> wheel

The packets seem to be definitely sent as needed. I added both the hid error (it was hid_err actually not hid_error but the compiler suggested it for me :D) and ran wireshark and after all that started fftest. On the first glance, everything is OK. If for any reason you want to see something beyond the screenshot, I attach the wireshark export file. It is .pcapng but I had to change the extension to attach.

So the only thing left is to try the LTS kernel. I'm going to do it right now

[creeper82]

Sadly, no improvement on the LTS kernel. That's weird

[Kimplul]

Sadly, no improvement on the LTS kernel. That's weird

Sort of expected, unfortunately, since you already showed that the wheel receives packets meant for it, meaning that the wheel is likely the culprit here (or at least that your wheel differs from mine in some non-obvious way). Could be a hardware revision requiring different handling, a bug in the firmware or something else entirely.

Beyond this point, debugging would likely require capturing packets from under Windows and try to figure out how they differ from the ones sent out by this driver. I wouldn't necessarily be surprised if the wheel requires some kind of different setup than what this driver does, but I unfortunately have no idea why or how :( Thrustmaster hardware is a bit of a mess.

[creeper82]

Crap, if only I have bought a Logitech wheel.. Still, T300 RS GT seems to be better than the G29 from what I've researched years ago. Since I never do racing, I don't mind the FFB so much, sometimes the auto center is enough (good thing I can at least adjust its strength), but it'd be a nice touch obviously to have FFB

I guess I'll try to compare the packets today or maybe in near future. Is the filter I used on the screenshot enough? Does it cover the initialization as well (since it's probably the initialization that's problematic?)

Damn, I really hate Thrustmaster for not providing better Linux support. It's a pity, as they have pretty good wheels

[Kimplul]

Does it cover the initialization as well (since it's probably the initialization that's problematic?)

I suspect initialization mainly uses a separate endpoint, 0, whereas the FFB commands use endpoint 1, so you'll likely have to play around with the filtering a bit. For instance, this driver tries to check the firmware version of the wheel by executing

hid-tmff2/src/tmt300rs/hid-tmt300rs.c

Line 1329 in 2699542

ret = usb_control_msg(t300rs->usbdev,

where the endpoint 0 is given to usb_rcvctrlpipe.

Looking at the capture, did you start it before plugging in the wheel? There should always be an open packet that gets sent out before FFB effects are uploaded, but the first packet I can see is setting the gain of the wheel and the other ones seem to be effect uploads/starts. Without open, the FFB effects will not play out. See

hid-tmff2/src/tmt300rs/hid-tmt300rs.c

Line 1265 in 2699542

static int t300rs_send_open(struct t300rs_device_entry *t300rs)

You can identify the open packet by the leftover capture data, should be 60 01 05 ...