support for thrustmaster tx leather edition

[patugo]

Is there work on supporting the thrustmaster tx leather edition? I've just got one, plugged it in and nothing is detected. :( Was hoping that it was supported, the wheel came out 4 years ago. On kde neon.

thanks.

[Kimplul]

I might be wrong, but I believe the TX is in the same camp as the TMX, namely that they both require some kind of followup to fully be initialized. Support for such wheels doesn't currently exist, I guess mostly because we don't own one to test with.

There seems to be a configuration file in tmdrv for the TX, though I'm not aware of a force feedback driver for it, so even if you get it initialized you would only have buttons, no rumbling etc.

[patugo]

"we don't own one to test with"... I have one and willing to help and test if instructions are given. Noob here.

I've done a bit of digging and: dmesg returns: 9/8/23 11:15 kernel usb 3-5.2: new full-speed USB device number 9 using xhci_hcd 9/8/23 11:15 kernel usb 3-5.2: New USB device found, idVendor=044f, idProduct=b664, bcdDevice= 1.01 9/8/23 11:15 kernel usb 3-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 9/8/23 11:15 kernel usb 3-5.2: Product: Thrustmaster TX GIP Racing Wheel 9/8/23 11:15 kernel usb 3-5.2: Manufacturer: Thrustmaster 9/8/23 11:15 kernel usb 3-5.2: SerialNumber: 0000000000000000

lsusb returns: Bus 003 Device 009: ID 044f:b664 ThrustMaster, Inc. Thrustmaster TX GIP Racing Wheel

Not perfectly the same model/device , tx gip vs tx leather, but might work anyway.

So ,after seing that, even if kde neon did see it their "game controller" application, I started eurotruck simulator 2. Sadly wheel/pedals are not displayed/seen.

I don't know if this is the right place, 'cause i've also seen something at https://github.com/Kimplul/hid-tmff2

Like I've said I'm willing to help if noob/clear instruction are given to fix this. :)

thank you.

[Kimplul]

"we don't own one to test with"... I have one and willing to help and test if instructions are given. Noob here.

Nice of you to offer, greatly appreciated.

Just to clarify some things, Thrustmaster wheels have a weird thing where they at first show up as a 'Generic Thrustmaster Wheel', after which they require your computer to send them some initialization packets that restart the wheel into a mode where it can generate force feedback (FFB). From there an 'actual' driver can pick up the wheel and start controlling the FFB and actually make it usable in games.

This driver is the first kind, just kickstarts the wheel, and projects such as https://github.com/Kimplul/hid-tmff2 are of the second, 'actual' driver type. In the TX's case it seems that both drivers need some work.

Speaking of, there's already an open issue about TX support over in https://github.com/Kimplul/hid-tmff2/issues/48. It's unclear to me how different the leather edition is from the base model, but I would assume it's still relevant to the discussion. Anycase, I'd recommend reading through the thread, there are some general outlines of what might need to be done and if you still feel up for helping then hit me up, we can go into more details.

[patugo]

ok, read the link on what to expect. Nothing dangerous except the mention "driver apparently causes the wheel to brick itself" but if does not apply to this case or just an eventual "unplug-replug" is enough and the modules wont "destroy" my linux installation (got this computer only, no other). I'm ready to follow/test instructions.

for information: o.s. = kde neon 5.27.7 uname -a = 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[Kimplul]

Great. I'm curious how similar the actual USB packet format is to the T300, would you mind doing some FFB captures? I have a short writeup of what to do over in https://github.com/Kimplul/hid-tmff2/wiki#how-to-capture-what-usb-packets-the-driver-sends-to-the-device. Forking the repo and uploading your captures to your fork might be a good way to share your captures.

As for buttons not working, did you test other games besides Eurotruck Simulator 2? Do the buttons work in other applications? For example, does evtest report anything happening when you press buttons?

[patugo]

done: -plug pedals to wheel base -plug power cord of wheel to current -plug usb of wheel to pc

-dmesg returns: [101101.487229] usb 3-5.2: new full-speed USB device number 13 using xhci_hcd [101101.811142] usb 3-5.2: New USB device found, idVendor=044f, idProduct=b664, bcdDevice= 1.01 [101101.811148] usb 3-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [101101.811149] usb 3-5.2: Product: Thrustmaster TX GIP Racing Wheel [101101.811150] usb 3-5.2: Manufacturer: Thrustmaster [101101.811151] usb 3-5.2: SerialNumber: 0000000000000000

-lsbusb: Bus 003 Device 013: ID 044f:b664 ThrustMaster, Inc. Thrustmaster TX GIP Racing Wheel

then I've done: sudo modprobe usbmon (no feedback or errors, I guess it's ok) sudo wireshark --select usbmon0

results: wireshark: besides the mouse input being seen, there's absolutely no other entry. xev: nothing is listed kde plasma game controller program: doesn't see a thing. Says it looked under /dev/js[0-4] and /dev/input/js[0-4] evtest: the "available devices" doesn't list the event where the wheel is connected

[Kimplul]

Pretty interesting, sounds like the wheel isn't reporting itself as a HID device. Are there different modes to the wheel? PS3/PS4/PC/XBox? If there are, which ones have you tried?

[patugo]

Don't think so. There's a button "mode" but that is to change the pedals mode, clutch/brake position. There's also a xbox button and a yellow one. Don't have a clue what they do. In any case I've asked them (ticket), I'll see what they reply.

[patugo]

While waiting for thrustmaster, I tried the following: -boot with windows pe (live iso) -download the driver ---wheel initializes itself (autocalibrate) but without the "xbox led light" -shutdown o.s. ---wheels turns off its leds -reboot -wheel recalibrates itself, led comes on and xbox led is still off -log into kde neon as normal -dmesg returns: [ 2.503975] usb 3-5.2: New USB device found, idVendor=044f, idProduct=b65d, bcdDevice= 1.00 [ 2.504476] usb 3-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.504970] usb 3-5.2: Product: Thrustmaster FFB Wheel [ 2.505448] usb 3-5.2: Manufacturer: Thrustmaster ... [ 7.309995] input: Thrustmaster Thrustmaster FFB Wheel as /devices/pci0000:00/0000:00:02.1/0000:02:00.0/0000:03:0c.0/0000:11:00.0/usb3/3-5/3-5.2/3-5.2:1.0/0003:044F:B65D.0004 /input/input8 [ 7.311463] hid-thrustmaster 0003:044F:B65D.0004: input,hidraw4: USB HID v1.00 Gamepad [Thrustmaster Thrustmaster FFB Wheel] on usb-0000:11:00.0-5.2/input0 [ 7.338332] hid-thrustmaster 0003:044F:B65D.0004: Unknown wheel's model id 0x104, unable to proceed further with wheel init -start kde game controller. Result = it sees the wheel and all buttons/pedals work. -sudo evtest. Result = all buttons/pedals work. -wireshark still sees nothing -game (euro truck sim 2) sees the wheel but doesn't seem to recognize the pedals (I didn't spend too much time figuring it out)

Rebooting pc/o.s. doesn't change anything to the above but if for whatever reason I unplug the wheel, either the usb cable or the power cord, the wheel initializes itself but with the xbox led on and linux ... back to square one.

[Kimplul]

You might want to look at installing Windows on a virtual machine so you don't have to reboot. I'm guessing you were trying to initialize the wheel on Windows and then bring the 'properly' initialized wheel over to Linux? Rebooting usually resets the wheel, but you might be able to pull it off with a virtual machine. Maybe, I'm not sure.

But yeah, other than that the dmesg output shows that the wheel is in its generic state and requires it to be initialized. hid-thrustmaster is the in-kernel version of this driver, and it notices an uninitialized Thrustmaster wheel and tries to initialize it, but as previously stated, there's no support for the wheel in the driver so it fails.

Could be useful to check which USB name, vendor ID and product ID the wheel shows up as under Windows, might be that the leather edition uses some other ID than the default TX wheel in which case tmdrv might initialize the wheel into the wrong mode. Though I'm sort of leaning towards the wheel just not reporting itself as a HID device for some reason, seems like the simplest explanation as to why no buttons show up in the initialized mode.

I'm not entirely sure what you're trying to look for with Wireshark under Linux, generally what I've used it for is situations where the wheel is connected to a virtual machine and looking at packets Windows sends to the wheel to figure out the 'correct' behaviour. Are you just checking to see if the wheel sends any packets whatsoever?

Rebooting pc/o.s. doesn't change anything to the above but if for whatever reason I unplug the wheel, either the usb cable or the power cord, the wheel initializes itself but with the xbox led on and linux ... back to square one.

Yeah, the wheel resets itself to the generic state every time it loses power.

[patugo]

hello,

The reason for running wireshark was that because you ask to run it before I ran it again in advance incase you needed it.

Anyway, here's what info I've got from windows (Booted into the live iso of winpe 10, to much hassle for now to install windows in vm)

-reboot pc -wheel plugged id -booted in winpe-10 -wheel is completely off -device manager just shows 4 generic human interface devices with nothing special (names, etc) -install driver -wheel comes alive and calibrates -in device manager, in human interface devices section is now populated with the following -in device manager, in human interface devices section: ----- hid-compliant game controller ----------location: on Thrustmaster Tx Racing Wheel (USB)

-in device manager, in human interface devices section, selected the Thrustmaster Tx Racin Wheel (USB) entry: --- General tab: ------- device type: Human Interface Devices ------- Manufacturer: Thrustmaster ------- Location: port#002.hub#0007 --- Details tab: ------- Device Description: Thrustmaster Tx Racing Wheel (USB) ------- Device instance path: USB\VID_0044F&PID_B669\9&6EC39FB&0&2 ------- Hardware id: ------------ USB\VID_0044F&PID_B669&REV_0100 ------------ USB\VID_0044F&PID_B669

hope this helps

thanks

[Kimplul]

The reason for running wireshark was that because you ask to run it before I ran it again in advance incase you needed it.

I'm afraid there's been a misunderstanding, the Wireshark stuff is for capturing USB packets between Windows and the wheel, not Linux and the wheel. We already know that the wheel doesn't work on Linux, so we would like to imitate the Windows driver to hopefully get the wheel working.

------- Hardware id: ------------ USB\VID_0044F&PID_B669&REV_0100 ------------ USB\VID_0044F&PID_B669

Somewhat interesting, ID b669 is on the list of IDs in tmrdv but your previous logs show b664. Are you sure tmdrv ran correctly? Or that the Windows drivers don't require a reboot or something? I would expect the wheel to have the same ID in Windows as it does with tmdrv, so something isn't adding up here.

[patugo]

The windows driver does say to reboot to use the software (control panel/etc) but the information in device manager is already there. If I reboot, all configs of the winpe live iso will obviously get lost.

"Are you sure tmdrv ran correctly?" --Don't know what you mean. How does one go about it?

[Kimplul]

The windows driver does say to reboot to use the software (control panel/etc) but the information in device manager is already there.

Some information, yes, but that might not be the information we're interested in. It seems possible that the wheel only initializes into the correct mode on reboot, though I don't know for sure.

--Don't know what you mean. How does one go about it?

Dunno, I suppose tmdrv would spit out some error messages, or dmesg didn't show devices attaching and reattaching themselves.

[davidedmundson]

I have a wireshark dump of the initial connections: http://static.davidedmundson.co.uk/thrustmaster_init.pcap

There seem to be two "set configuration" requests. bRequest = 9 bConfigurationValue = 0

and then a bConfigurationValue of 1.

I've also started dumping the general settings.

Auto-centre is an additional data blob, with 3 relevant bytes.

header.cmd = 40
header.code = 03
value = 0-100 as a single byte 

Which is similarish to the T300, but different enough that we won't be able to re-use it

[davidedmundson]

Sorry to ask for tech support in an issue tracker, but I'm missing something stupid and been stumped for hours

It appears in lsusb as Bus 001 Device 013: ID 044f:b664 ThrustMaster, Inc. Thrustmaster TX GIP Racing Wheel

so I started the obvious:

static const struct hid_device_id tminit_devices[] = {
    { HID_USB_DEVICE(0x044f, 0xb65d)},
+   { HID_USB_DEVICE(0x044f, 0xb664)},
    {}
};

I'm not having the probe function called. I put printk's there and nothing is happening.

I'm definitely installed correctly as I can change the module description and modinfo picks up that's changing.

Dumping the modules.alias file contains: hid:b0003g*v0000044Fp0000B664 which is my new entry. No other module alias contains b664 so nothing should be clashing. I blacklisted hid_thrustmaster anyway.

The mod alias of the device is through /sys is usb:v044FpB664d0101dcFFdscFFdpFFicFFisc47ipD0in00 Not sure how that maps to hid directly.

[Kimplul]

Just a theory, but the driver requests HID devices, and if the wheel shows up as a plain USB device the probe might not be executed. I'm not entirely sure if the USB subsystem in Linux actually cares about this distinction, should do a code reading session. Technically this driver doesn't really care about the HID capabilities, so converting it to use raw USB might be useful to make some stragglers like the TX easier to add.

[davidedmundson]

That makes so much sense. The current interfaceClass is "vendor specific" not HID.

As a test I also registered for
{ HID_USB_DEVICE(0x044f, 0xb669)}, // TX active in the driver and sent the magic packets with tmdrv.

Once it got the modeswitch it re-appeared under the new USB ID, interface class changed and my print statements appeared. So the theory seems to hold.

[Kimplul]

Thanks for the confirmation, I'll try to patch the driver to not rely on HID but I'm a bit swamped for at least a couple weeks, sorry. If you want to give it a shot feel free to, but in either case I still think it would be more valuable to try and get a feel for the active (good word for it btw, easier to follow than 'actual' etc) driver and what might be required for it to work.

Since tmdrv seems to work, the init driver would mostly be a convenience to be included in the kernel so people don't have to install external stuff. At least that's what we initially were going for, I for one still haven't sent patches for my hid-tmff2, and without it the init driver is kind of useless.

[davidedmundson]

If you want to give it a shot feel free to

Will do.

either case I still think it would be more valuable to try and get a feel for the active

Ack, I'll start hacking on that and report back. Thanks for the help so far.

[davidedmundson]

I have good news throughout.

I updated to the latest firmware and did some wiresharking. set gain and set autocentre were now behaving exactly the same as the T300 play, stop effects were the same and constant force had the same looking header

open and close don't match the t300, but do match the T248 (with some extra packets that seem to be ignoreable)

I did a fast hookup to the t248 and I had all FF working, even out of the box in the game Grid. I need some time to restore all the firmware checks and everything, but it looks very doable.

Since sorting this driver, input mapping is all over the shop, I assume this relates to the wheel_fixup callback? I don't understand quite how that's generated.

[Kimplul]

Wow, that's fantastic. Really wasn't expecting anything to happen, the other thread made the situation sound a whole lot more complicated. Well done.

Which firmware version do you have installed? Might be a good idea to tag it somewhere as a known good minimum version or something.

Since sorting this driver, input mapping is all over the shop, I assume this relates to the wheel_fixup callback?

Yep, that's right. HID devices send a binary dump to the host system that contains info about which buttons the device supports, which axis they should be mapped to and so on. This allows implementers to write generic drivers for a multitude of devices, as long as the information contained in the dump is accurate.

A table of values and their meaning can be found over at https://usb.org/document-library/hid-usage-tables-14

and a tool to let you play with them over at https://usb.org/document-library/hid-descriptor-tool

The tool is Windows only so you'll need Wine. Also, the USB website claims it's deprecated but I haven't seen any alternatives to it, maybe I've just missed them.

Anyway, in the case of the T300 and the T248, it turned out that the dump was in fact inaccurate. The inputs were correct, but I had to modify some endpoint usage values, for example see here https://github.com/Kimplul/hid-tmff2/blob/010c0d986d8d75ff2727d164c8c41b08b33549a9/hid-tmt300rs.c#L134 and here https://github.com/Kimplul/hid-tmff2/blob/010c0d986d8d75ff2727d164c8c41b08b33549a9/hid-tmt300rs.c#L132

Per the comment, apparently the previous values were 0x10 but I had to change them to 0x60 before any FFB started working. Unfortunately I have no idea what the values mean, they're in a vendor-specific region and I mostly just stumbled upon them.

I'm unsure if it might be better to try and capture the HID dump for the TX and then modify the FFB values or try to modify the T248 config to get buttons working, up to you. In the former case, with the driver unloaded you should be able to get a hexdump from the command line with something like

sudo cat /sys/kernel/debug/hid/XXXX\:044F\:B669.XXXX/rdesc

The actual path might vary from boot to boot, but look for the wheel's VID/PID pair.

[Kimplul]

Hi again @patugo, @davidedmundson submitted a patch with TX FFB to https://github.com/Kimplul/hid-tmff2, would be great if you could check it out. At the moment it still requires tmrdv to initialize the wheel.

I also pinged https://github.com/Kimplul/hid-tmff2/issues/48, if you have any issues with or further comments about the FFB please submit them over there.

[patugo]

tried it, did not work.

tried: -downloaded tmdrv -installed python3-libusb1 -ran: ./tmdrv.py -D (got Thrustmaster T500RS, Thrustmaster TX, Thrustmaster TMX, Thrustmaster TS-XW) -ran: ./tmdrv.py -d thrustmaster_tx Got a lot of errors, but I still ran the instructions: --- apt install linux-headers-$(uname -r) --- git clone --recurse-submodules https://github.com/Kimplul/hid-tmff2.git --- make --- sudo make install -Plug wheel back in -reboot

[Kimplul]

Try running ./tmrdrv.py ... after the reboot. The wheel has to be initialized every time you start your computer, unfortunately.

What errors did you get? Something about SSL?

[patugo]

Sorry, ran the tmdrv without sudo. Now I did and it works.

thanks very much.

I get an error: "jscal not found, skipping device calibration." But that's no big deal, the wheel does its own calibration.

results of dmesg: er Thrustmaster TX Racing Wheel as /devices/pci0000:00/0000:00:02.1/0000:02:00.0/0000:03:0c.0/0000:11:00.0/usb3/3-5/3-5.2/3-5.2:1.0/0003:044F:B669.0006/input/input20 [ 232.997286] hid-generic 0003:044F:B669.0006: input,hidraw4: USB HID v1.11 Joystick [Thrustmaster Thrustmaster TX Racing Wheel] on usb-0000:11:00.0-5.2/input0 [ 233.164472] input: Thrustmaster Thrustmaster TX Racing Wheel as /devices/pci0000:00/0000:00:02.1/0000:02:00.0/0000:03:0c.0/0000:11:00.0/usb3/3-5/3-5.2/3-5.2:1.0/0003:044F:B669.0006/input/input21 [ 233.224014] tmff2 0003:044F:B669.0006: input,hidraw4: USB HID v1.11 Joystick [Thrustmaster Thrustmaster TX Racing Wheel] on usb-0000:11:00.0-5.2/input0 [ 233.251826] tmff2 0003:044F:B669.0006: force feedback for TX

It's detected has tx racing... not tx leather (but I don't think it matters) Is there a terminal command to test forcefeed back?

thanks

[Kimplul]

Is there a terminal command to test forcefeed back?

fftest /dev/input/by-id/usb-SOMETHING comes to mind. Replace SOMETHING with the name of your wheel, just press tab until you see the alternatives.

[davidedmundson]

Make sure to use the input device with -event- in the name.

A potentially simpler test is ffset.

ffset -a 1 /dev/input/by-id/usb-Thrustmaster_Thrustmaster_TX_Racing_Wheel-event-joystick wheel should spin loosely

ffset -a 100 /dev/input/by-id/usb-Thrustmaster_Thrustmaster_TX_Racing_Wheel-event-joystick wheel should be hard to turn

[patugo]

tried: sudo fftest /dev/input/by-id/usb-Thrustmaster_Thrustmaster_TX_Racing_Wheel-event-joystick

gives options/effects to try. None of them work.

running: ffset .... doesn't change a thing. It just returns : "Device /dev/input/by-id/usb-Thrustmaster_Thrustmaster_TX_Racing_Wheel-event-joystick opened"

[patugo]

I had to find a way to install new firmware of the wheel. Did it and now it works doing: -reboot and login -plug the wheel (power and usb) -do sudo ./tmdrv.py -d thrustmaster_tx -run the game

Sadly when i put pc to sleep and bring it back, the force feedback doesn't work anymore.