WIP: T818 support

[schlegp]

Hi there.
The T818 has the same device ID as the T248 (b696) so it is immediately picked up by hid-tmff2 and usable.
I recently noticed that it's feeling different than on Windows, so I decided to capture USB packets and check if I can see any differences between Linux and Windows.

This issue is intended as a place for me to gather my findings and for people to chime in if they already have some information.

To find packets differing between Windows and Linux I for now resorted to recording USB packets while running rFactor 2 and comparing the used commands. Most of them are the same but there is one command that is sent a few times that does not seem to be sent by hid-tmff-new.

60 00 --- Default Header
01 --- ID
0b --- Unknown Command
00 00
37 fd --- Unknown values
00 00
ff ff --- Unknown vlaues
00 80 --- Unknown values

I was unable to recreate this command with fedit.exe for now, so I have no clue what it does.
I don't quite understand the code inside t248.c yet, though, so it might be that it was already deciphered.

If anyone cares to chip in or help out, feel free!

[Kimplul]

The T818 has the same device ID as the T248 (b696) so it is immediately picked up by hid-tmff2 and usable.

Surprising, but cool.

I don't quite understand the code inside t248.c yet, though, so it might be that it was already deciphered.

Not that I'm aware of. The T248 uses the same effect packets as the T300RS, which I've 'documented' in force-effects.txt. The packets that are documented are completely based on fedit, which provides access to 'basic' force feedback types. 0b isn't a command I've stumbled upon previously.

Pure speculation, but I would assume the mystery packet(s) are either related to the Custom FFB type, for example documented in SDL, or something do with tm_api_lib_x64.dll. I haven't implemented Custom FFB type handling (mostly because I mainly used fedit to do my packet generation, which doesn't support it) which could be the issue. Or, tm_api_lib_x64.dll knows something about the wheel that we don't and the Windows driver provides some non-standard way to communicate with the wheel that only the library knows about. I don't know much about the library, haven't found any documentation about it.

The Thrustmaster control panel also has some test effects that I couldn't replicate in fedit, could be that they also use either of the above methods.

Considering SDL provides a Custom FFB type, it might be worth it to try and check that route first. I don't really know how the type is supposed to be used, healthy amounts of experimentation may be in order.

[schlegp]

I remember hearing in a review that the T128, T248 and T818 all have the same name in Windows as Thrustmaster Advance Racer, seems to me they unified their software in some way.

I checked to see if tm_sdk_api_lib_testapp_x64.exe provided in the wheels driver produces this command but it seems to only be sending the known simple commands.
I've opened a support ticket with thrustmaster requesting support/info on this topic from their side on the off-chance they might help.

I will check out SDL Custom FFB types now, thanks for the idea.

[berarma]

I did extensive testing with rFactor 2 on Logitech wheels using ffbtools three years ago. It only uses a sine wave with amplitude zero and an offset that simulates a constant force. In my experience, the game is handing internally all the effects and sending to the wheel the resulting constant force. I would be surprised if it used custom effects on some wheels, but it's possible.

Could it be something related to displays, leds, or something similar in the wheel?

Ffbtools has a tool to send raw commands to any USB device from the terminal for testing.

[Kimplul]

Could it be something related to displays, leds, or something similar in the wheel?

Entirely possible, though the packet format looks very similar to force feedback packets. Could be double purpose, I don't know. @schlegp saying the game feels different would also point towards the packet having something to do with FFB, but at the same time it's entirely possible the difference could be from how my driver translates the effects to packets compared to the Windows driver, even if the same effect types are used. Slightly different delays, magnitudes, etc.

Can't remember off the top of my head if rFactor 2 uses tm_api_lib, should check.

That being said, rFactor 2 is on the list of games that allegedly feel different with the driver installed in the Wine prefix:
#46 (comment)

@schlegp did you already try installing the Thrustmaster drivers inside the prefix?

[schlegp]

I've been able to do some more testing yesterday and have some more understandings.
Under windows the wheel gets sent 200 packets per second, so setting hid-tmff-new timer_msecs=5 already improves the feeling of the wheel.

I had already installed the Thrustmaster driver in the games prefix, so I tested the feedback without the driver installed. Interestingly it seemed to feel identical. So either the drivers do not need to be installed anymore, or they are not active after being installed. I tried running wineboot in the prefix to fake a reboot, as the driver prompts you for that after installing, but that did not seem to help.

I was however able to find a situation where this force feedback differs most.
When driving FWD cars, on throttle with a bit of steering input the steering wheel typically gets lighter. This effect is way more pronounced when running under linux than on windows. It almost feels like there is no FFB-effect applied in this situation.
Maybe someone with a different wheel reads this and can try this on the T300 or something. (I've been testing with the BTCC Ford Focus; BTCC Toyota Corolla)

@berarma The tool for sending raw commands to the wheel seems like exactly what would help pinpoint this issue, I will record another session and then try sending a few of these unknown packages to see what they might be doing.

[schlegp]

Update on the current situation: Sending the unknown command to the base directly did not do anything really, although this might also be down to doing something wrong.

I found a new command that is being sent by Windows but not by Linux, namely 60 00 01 8e. Other commands do also differ but until I find a way to isolate them it's hard to know what they do.

I compared the feeling of FFB in ACC aswell now, there you can feel a stark difference. On Windows you get the feeling of actually feeling the road, while on Linux it feels like you only feel the greater forces acting on the wheel.
The suspicion arises that the driver does not actually help out for this wheel when running in Proton. Maybe that's the cause of the issues in the end.

I decided to use the work of @berarma and use their rawcmd tool to create a little "replay" utility. The intention is to send all force feedback commands captured by wireshark back to the wheelbase with the added possibility of ignoring selected commands.
I hope to somehow figure out what kind of effects might be missing when not sending the unknown commands.

[Kimplul]

Sending the unknown command to the base directly did not do anything really, although this might also be down to doing something wrong.

Not sure if related, but the wheel has to be initialized to an 'open' mode before it actually accepts FFB packets. See https://github.com/Kimplul/hid-tmff2/blob/master/hid-tmt300rs.c#L1417 for the values used, or you could try setting the module parameter open_mode=0, which initializes the wheel into the open mode when connected. Usually the wheel mode is changed when the device is open()ed, but I don't know if sending raw commands bypasses the mode switching. Probably not, but thought it was worth mentioning.

Some other things to maybe keep in mind:

• Some effects are passive or react to the wheel position, so try to make sure you're turning the wheel to not miss something subtle.
• The commands might change some internal mode in the firmware, could maybe make the wheel react to incoming packets differently. Likely worth sending out a series of packets, probably what you're trying to with the replay utility you mentioned. I'd love to get to play around with it, by the way.

Also, would you mind sharing some of your Windows USB packet captures? I can try sending some raw commands to my wheels, see if I can get anything interesting to happen.

The suspicion arises that the driver does not actually help out for this wheel when running in Proton. Maybe that's the cause of the issues in the end.

Interesting thought, but no clue why that would be. I personally didn't feel a huge difference between no driver/driver in the games I tested, but I wouldn't say there was no difference.

[schlegp]

So, I have thrown together something simple for now that works quite reliably.
https://github.com/schlegp/tmff-replay
The tool can replay a session that was exported as csv from wireshark. I have not been able to get it working on linux yet, seems to be more complicated to force the wheel to connect using the libusb driver. (Probably some udev rules I would have to set up for that?)

For now I tested it running Assetto Corsa Competizione, driving a Porsche around Kyalami. I couldn't feel a difference, although it's hard to replicate the steering wheel movements just by feeling where the car could be using the FFB.
I have filtered out the unknown command during one session but was not able to feel any difference as of yet.

Next up is some testing with rFactor 2 and other things.

In other good news:
I received a response from Thrustmaster Support, they have forwarded my request regarding the commands to their R&D-Department and will get back to me once workload allows it.

Edit: I have also added two wireshark recordings to my repository. The smaller file is just me setting Gain to 100, Damping to 0, Mode to Extreme and running the Force Feedback Test and the long one is the mentioned Porsche Lap around Kyalami with around 50 seconds of setup (setting gain to 100% and starting the game).

[schlegp]

I was able to make some progress on this issue in the last days. Sadly nothing new about the mysterious "0b" command, I never got a follow up from the Developers or anyone.
I have a month of freetime now, let's see how far along I can get this issue.

I created a fork of this project, as the ProductId of the T248 and the T818 are identical and I did not want to break compatibility. The two wheels have different ranges, so finding a way to differentiate these two would be great.
I implemented the "Driver Mode" and corrected the wheel range for the T818.

The driver mode has four values: From 'Comfort' to 'Extreme' and seems to be a damping effect smoothing out the output.

Setting this to extreme and setting the correct wheel range gets the feeling of the steering wheel way closer to the windows experience.

Next up on my To-Do-List is to find this mysterious package that is not reproducible. It does not get used at all when running all available DirectInput ForceFeedback effects.
I have a hunch it might be connected to tmInstall.EXE that is loaded into the game at startup, but I have not found a way to get a look inside that yet.

Next up I check the Wine dinput logs to see if I can identify the CreateEffect-Call responsible for the 0b-packet or at least see where it takes me from there.

At least I got RGB-Controls working, so that's nice.

[Kimplul]

I was able to make some progress on this issue in the last days. Sadly nothing new about the mysterious "0b" command, I never got a follow up from the Developers or anyone.

Glad to hear you're making progress. Not exactly surprised Thrustmaster doesn't want to help in this case, but it was worth a shot.

I created a fork of this project, as the ProductId of the T248 and the T818 are identical and I did not want to break compatibility. The two wheels have different ranges, so finding a way to differentiate these two would be great.

A number of T-series wheels have a special packet to query data from the device, including wheel base and attachment data, used for example here:

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

Line 1522 in ca16863

static int t300rs_get_attachment(struct t300rs_device_entry *t300rs)

I'm not sure but wouldn't be surprised if it worked on the T818 as well. Some example outputs can be seen here: https://github.com/scarburato/hid-tminit/tree/9375f6c7d83af5dd6c8b8fe30351d0f36043b20a#recapitulatory-table

Maybe try checking if your captures have it as well, it usually shows up multiple times when you plug the wheel in.

[hodasemi]

Hi guys,
I saw that @schlegp's work and was wandering if there are plans to merge these changes into this project as his last commit is also over a year back.

[schlegp]

Hi @hodasemi,
I did not really find the time anymore to work on it, but I have the driver feeling the same as in windows. I never solved the mystery packages being sent, but I also could not feel a difference, at least in AMS2 and ACC.

The T818 is configured differently than the old belt driven wheels were. Instead of spring and friction you now have a "Mode" and "Linearity" value that you can set.
With this changes in Oversteer are needed aswell, that I hacked in for now.

Basically I would need to do some cleanup work and could then probably merge it into tmff2 again.

Hearing there's other people wanting to use this wheel on Linux gave me new motivation at least. :)

[hodasemi]

@schlegp hit me up if you need any help.

I never used the T818 in windows, thus I don't have any reference, but hearing that there are some options available is always awesome.