spring, damper, periodic, constant

[albfan]

With this explanation:

https://www.youtube.com/watch?v=GvoR_4hcxmc

and reviewing what hid-tmff2 does, all this are just configuration values that wheel uses to reproduce a force a game send to wheel. A periodic force if you are on a curve, a spring to recover wheel position, etc..

hid-tmff2 just store those values and uses when there's a report to apply an effect (am I right @Kimplul?)

That's why there's not effect on capturing changes on control panel to this values

This needs to capture a game sending reports to driver, and see how effect changes depending on that setup.

[Kimplul]

If I understand your question correctly, yeah, the control panel values (Oversteer/Thrustmaster control panel) are not directly sent to the wheel, instead they get applied to a force effect when a game tries to send one out. The wheel itself doesn't apply any corrections, as far as I'm aware.

[albfan]

Doing more tries, after apply an effect from control panel, I see some hid data starting with 0x02 and 0x04 moving those percentages

Will upload some captures and try to figure out how this works

[albfan]

Using a stock photo for reference

sliders for constant, periodic, spring and damper forces only works when effect is active.

each time you focus in/out from control panel a 0x4205 is sent.

if you start an effect like "Blown tire" effect this data is sent:

41 01 41 01
41 00 41 01 

At this point sliders send info if you move them.

When you focus out, it stop too the effects:

42 05
41 01 00 01
41 00 00 01 

then sliders do not send anything anymore

Different effects attend to different sliders, I couldn't find any effect attending to spring force (which is an effect for a supposed spring on wheel, so might make sense for that list of effects)

fftest might help here, but I guess we can found by discard

When "Blown tire" is enabled, moving constant force driver sent (last hex byte):

03 1e 03 ff (0%)
03 1e 03 c0 (100%)

255 - 192 =63 possible values. Looks kind strange, but, 50% value is e0 (224) 255 -224 = 31, middle of those values

For periodic forces it is (last hex byte):

02 c0 01 d9 00 00 aa 02 00 (0%) 0
02 c0 01 d9 00 00 aa 02 2c (50%) 44
02 c0 01 d9 00 00 aa 02 58 (100%) 88

Punch effect allows to expose damper force (repeated on 4 and 5 hex byte):

05 ae 02 00 00 00 00 00 00 64 64 (0%) 0
05 ae 02 32 32 00 00 00 00 64 64 (50%) 50
05 ae 02 64 64 00 00 00 00 64 64 (100%) 100

second hex byte can change ae, e6, not sure how that affects

At least to implement this controls it might be enough. Let's add a fftest dump to compare what linux driver launch

wheelcheck shows too valuable info, and shows controls for spring force

With all that info, there's a start setup every time we start an effect, where all these current values are sent:

Effect "Blow tire" send (all forces 100%):

41 00 00 01

02 48 03 d9 00 00 aa 02 58 (periodic 100%)
04 3a 03 0a 00 00 22 02
01 00 20 40 e2 04 00 00 00 3a 03 48 03 00 00

41 01 00 01

02 64 03 00 00 7f 00 00 7f
03 56 03 c0  (constant force 100%)
01 01 00 40 84 03 00 00 00 56 03 64 03 00 00

Not always it send 3 messages, but as some of them are recognizable, probaby we can identify what the other messages are related with.

On wheelcheck I see several concepts present on tmff2 driver (coefficient, saturation) so maybe we can share same implementation (or merge drivers at some point) even merge upstream @Kimplul?

[albfan]

https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c#L277

Just enabling spring effect you can feel how a free wheel start to apply some force. We can replicate that effect and see hid messages sent from windows and fftest till this gets implemented

[Kimplul]

On wheelcheck I see several concepts present on tmff2 driver (coefficient, saturation) so maybe we can share same implementation (or merge drivers at some point) even merge upstream @Kimplul?

Sure, I'm all for it. There was a bit of discussion about merging T150 functionality into hid-tmff2 in Kimplul/hid-tmff2#78, but I don't know what the status on that is.

[pastaq]

On wheelcheck I see several concepts present on tmff2 driver (coefficient, saturation) so maybe we can share same implementation (or merge drivers at some point) even merge upstream @Kimplul?

Sure, I'm all for it. There was a bit of discussion about merging T150 functionality into hid-tmff2 in Kimplul/hid-tmff2#78, but I don't know what the status on that is.

The status is I want to go in a different direction. I posted a discussion thread on the hid-tmff2 github to begin, but the BLUF is that I want to work on getting support merged upstream.

Kimplul/hid-tmff2#159

T150/TMX will be the first devices supported. I'll need assistance from this group as well as credit affiliations, much of the work will need to reference what exists in these two drivers.

[albfan]

Exciting, would be awesome to reach upstream and merge all this work.