libbeamng.| Steering wheel drivers didn't provide any FFB resolution information. Defaulting to 65536 steps and wheel getting "stuck" sometimes in beamng about hid-tmff2

[WhiteHusky]

@kevenwyld mentioning my patch.

Oh hey. It's nice seeing my patch being useful and right when I'm about to get a T300RS.

Small world.

[Kimplul]

I could definitely follow some guides if you could help point me in the right direction.

I wrote up a quick (and very dirty) wiki page: https://github.com/Kimplul/hid-tmff2/wiki

Any improvements and suggestions/requests for clarifications are of course welcome.

[kevenwyld]

While not entirely related to this issue I collected some proton debug logs that might be of interest to this discussion over in the proton beamng thread .

The situation has otherwise not changed though even in the 0.29 release. The workaround above still seems to work though, so that's good.

[Kimplul]

Thanks for the report. I have no idea what FFB resolution the game is talking about, I'll have to see if I can find some info on it. About getting stuck, I had to turn on inverted FFB from the game's FFB settings for it to work properly. Not sure if something could be changed to make the game figure out the direction by default, but at least it's an easy fix.

[kevenwyld]

I feel like I'm just not understanding how the damping is suppose to work maybe, this is my first high output wheel (had a G27 before) so I'm sorry if it turns out that I'm just not using it correctly.

After more experimentation I'm able to reproduce this pretty much immediately by taking a sharp turn and then quickly bringing the wheel back to center and stopping the vehicle. Here's some videos of the issue. I disabled the in game FFB setting reduce strength at park to make the issue appear more easily in the second video, but it's the same thing that happens occasionally in game. In the first video the in game FFB settings are default except for inverted which is checked.

EDIT: Notice how in the first video when I finally get the car moving backwards the oscillation doesn't change the direction or movement of the vehicle at all. I'm not sure what to make of that, but thought it was worth pointing out.

Files are too large for github so I put them on vimeo, sorry about the one-handed vertical video, it's the best I could do trying to hold everything:

https://vimeo.com/667966036

https://vimeo.com/667967958

Here's some things I tried which didn't seem to make much difference:

• adjusted smoothing between 0 and 500, nothing seemed to change much although the engine vibration effect is much more pronounced at lower values as expected
• tried a few different update rate limits including automatic
• tried both update type options
• adjusted the wheel timer_msecs parameter (I set it to 2ms like the other issue mentioned in the readme)
• using oversteer to change the damper effect gain (It's not clear whether these take effect immediately or not but I think they do)

[Kimplul]

Interesting, thanks for the videos. I'll try to fiddle around and see if I can replicate the behaviour, I don't have a lot of time in BeamNG and probably missed something last time around. This might relate to some issues I've had with the periodic effect or some combination of periodic + spring, not sure. Somewhat unfortunately I woke up today to find that my pedals have started misbehaving, both on Linux with my driver and on Windows. I'll see if I can get them to work or maybe just order a new pair if that fails, but there could be a pretty big delay before I can figure this out (if at all), sorry in advance.

using oversteer to change the damper effect gain (It's not clear whether these take effect immediately or not but I think they do)

Technically they take effect on the next effect update, which is usually immediate.

[kevenwyld]

Somewhat unfortunately I woke up today to find that my pedals have started misbehaving, both on Linux with my driver and on Windows.

Sorry to hear that, if there's anything I can do to help please ask.

there could be a pretty big delay [...] sorry in advance.

No problem at all, you are volunteering your time as it is. We all appreciate that you have put your free time into this project.

This might relate to some issues I've had with the periodic effect or some combination of periodic + spring, not sure

I poked around with debugging the module with gdb but didn't get very far yet. If I can make that work I will report back with the logs. I'm interested to see if I can isolate what effects are being transmitted during these "stuck" periods and if that might help.

[kevenwyld]

The "sticking" appears to be an issue with the Soft lock setting in beamng's FFB configuration. If I disable soft lock I can no longer reproduce the issue.

[Kimplul]

Alright, glad you found a workaround. I'll still have a look into the stuff mentioned in this thread, but I just can't get my pedals to work. I'll probably just order a new pair, isn't the first time I've broken some Thrustmaster device.

Anything to note about disabling the soft lock, or does it 'just work'?

[kevenwyld]

Disabling the soft lock seems to clear up the unexpected oscillations and sticking completely. I would say that not using soft lock is a major issue in beamng specifically though since each car has a different simulated steering rack and part of the fun of the game is going between them to experience different types of cars/configurations (rally spec -> rock crawler -> track car -> etc.).

That's too bad about your pedals. In the mean time I noticed that you don't have any debug documentation in the repo. I'm not that experienced with kernel module development but I could definitely follow some guides if you could help point me in the right direction. It seems to me that if one could simply log the effects being used it would help track down this issue pretty quickly. I'm just not sure where to start with that.

Here's the behavior I've experienced and how to reproduce the issue in beamng for future reference:

1. Select a car with short steering, any of the rally cars work for this
2. make sure FFB is on with default settings and "soft lock" is checked
3. drive at a slow speed and rapidly turn the wheel as quickly as possible against the soft lock limiter
4. let go of the wheel (I know this isn't recommended with FFB systems but in this instance it reproduces the issue consistently)

Once I do this the wheel rapidly turns to a point that is beyond the soft lock, usually opposite the side I initially turned to, and begins oscillating between 0 and 90deg. Grabbing the wheel and attempting to stop the oscillation requires a large amount of force and you have to force it back into the soft lock region of rotation. After that you can drive normally until you hit the soft lock again.

I initially noticed this when attempting to drift on loose surfaces since I would only have one hand on the wheel and the other operating the hand brake. Once I hit the lock it would rip the wheel out of my hand and enter this state.

[arabek]

Have you tried the soft lock setting with driver set to a higher sampling rate? There is an option for that when loading the module. It might be that the driver is missing some events due to default 8ms. Try setting it to a lower value (I use 2ms) and retest.

[kevenwyld]

Have you tried the soft lock setting with driver set to a higher sampling rate? There is an option for that when loading the module. It might be that the driver is missing some events due to default 8ms. Try setting it to a lower value (I use 2ms) and retest.

I have this set to 2ms with /etc/modprobe.d/hid-tmt300rs.conf containing options hid-tmt300rs timer_msecs=2. This didn't seem to make any difference.

There is some update rate limit tuning in the game as well (default is auto with various options measured in Hz). I messed with this a bit as well but there was no change.

[kevenwyld]

Ok, so more information.... though I'm not sure it really points to a problem yet other than beamng having a not so ideal implementation of FFB.... I've done a comparison of beamng to Dirt Rally 2.0 below. Both are proton games.

The log I've posted from beamng is during a period where I am experiencing the oscillations which are outside the soft lock limit set in the game. It's the same type:CONSTANT and level:-32768 over and over.

It appears that beamng does not use any of the features provided by the wheel other than constant even under normal circumstances. I'm not experienced enough with FFB to say whether that's an issue or not but it doesn't seem right to me.
EDIT: Sounds like this is on purpose, https://beamng.com/threads/force-feedback-experiments-with-t300-rs.49547/#post-742120

An excerpt of the ffb log from beamng:

000585841808 < 24
000585842576 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585842589 < 0 id:0
000585850337 > PLAY 0 2147483647
000585850361 < 24
000585851330 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585851344 < 0 id:0
000585858648 > PLAY 0 2147483647
000585858670 < 24
000585859298 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585859312 < 0 id:0
000585867928 > PLAY 0 2147483647
000585867952 < 24
000585868642 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585868656 < 0 id:0
000585876626 > PLAY 0 2147483647
000585876653 < 24
000585877470 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585877485 < 0 id:0
000585884928 > PLAY 0 2147483647
000585884951 < 24
000585885628 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585885642 < 0 id:0
000585893167 > PLAY 0 2147483647
000585893191 < 24
000585893914 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585893928 < 0 id:0
000585901387 > PLAY 0 2147483647
000585901407 < 24
000585902050 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585902063 < 0 id:0
000585909914 > PLAY 0 2147483647
000585909942 < 24
000585910802 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585910816 < 0 id:0
000585918455 > PLAY 0 2147483647
000585918478 < 24
000585919149 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585919162 < 0 id:0
000585926803 > PLAY 0 2147483647
000585926825 < 24
000585927460 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585927473 < 0 id:0
000585935219 > PLAY 0 2147483647
000585935240 < 24
000585935878 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000585935891 < 0 id:0
000585944186 > PLAY 0 2147483647
000585944211 < 24
000585945317 > UPLOAD id:0 dir:49152 length:0 delay:0 type:CONSTANT level:-32768 attack_length:0 attack_level:0 fade_length:0 fade_level:0

And an excerpt from Dirt Rally 2.0:

000002575120 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002575143 < 0 id:0
000002575148 > PLAY 0 1
000002575152 < 24
000002575158 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002575165 < 0 id:3
000002575169 > PLAY 3 1
000002575172 < 24
000002585241 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002585261 < 0 id:0
000002585266 > PLAY 0 1
000002585270 < 24
000002585276 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002585280 < 0 id:3
000002585283 > PLAY 3 1
000002585287 < 24
000002595363 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002595384 < 0 id:0
000002595389 > PLAY 0 1
000002595393 < 24
000002595399 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002595403 < 0 id:3
000002595406 > PLAY 3 1
000002595409 < 24
000002605489 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002605509 < 0 id:0
000002605516 > PLAY 0 1
000002605520 < 24
000002605526 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002605530 < 0 id:3
000002605534 > PLAY 3 1
000002605547 < 24
000002615630 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002615649 < 0 id:0
000002615654 > PLAY 0 1
000002615659 < 24
000002615665 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002615668 < 0 id:3
000002615672 > PLAY 3 1
000002615675 < 24
000002625758 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002625780 < 0 id:0
000002625786 > PLAY 0 1
000002625791 < 24
000002625797 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002625802 < 0 id:3
000002625805 > PLAY 3 1
000002625809 < 24
000002635889 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002635910 < 0 id:0
000002635915 > PLAY 0 1
000002635919 < 24
000002635926 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002635929 < 0 id:3
000002635933 > PLAY 3 1
000002635936 < 24
000002646017 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002646039 < 0 id:0
000002646045 > PLAY 0 1
000002646050 < 24
000002646056 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002646063 < 0 id:3
000002646066 > PLAY 3 1
000002646072 < 24
000002656152 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002656173 < 0 id:0
000002656178 > PLAY 0 1
000002656182 < 24
000002656188 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002656192 < 0 id:3
000002656195 > PLAY 3 1
000002656199 < 24
000002666281 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002666305 < 0 id:0
000002666310 > PLAY 0 1
000002666315 < 24
000002666323 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002666327 < 0 id:3
000002666330 > PLAY 3 1
000002666334 < 24
000002676413 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002676436 < 0 id:0
000002676441 > PLAY 0 1
000002676445 < 24
000002676451 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002676455 < 0 id:3
000002676458 > PLAY 3 1
000002676461 < 24
000002686542 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002686566 < 0 id:0
000002686571 > PLAY 0 1
000002686576 < 24
000002686582 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002686586 < 0 id:3
000002686589 > PLAY 3 1
000002686592 < 24
000002696632 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002696655 < 0 id:0
000002696661 > PLAY 0 1
000002696667 < 24
000002696674 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002696678 < 0 id:3
000002696682 > PLAY 3 1
000002696685 < 24
000002706768 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000002706790 < 0 id:0
000002706795 > PLAY 0 1
000002706799 < 24
000002706806 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:0 left_coeff:0 deadband:0 center:0
000002706823 < 0 id:3
000002706827 > PLAY 3 1
000002706831 < 24

[kevenwyld]

Here's another excerpt from Dirt Rally 2.0 which maybe has some more interesting things going on instead of just max friction and constant level:0:. It still only uses those two effects though.

000091419612 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-6717 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091419636 < 0 id:0
000091419642 > PLAY 0 1
000091419646 < 24
000091419652 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16050 left_co
eff:16050 deadband:0 center:0
000091419656 < 0 id:3
000091419659 > PLAY 3 1
000091419662 < 24
000091429750 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-4951 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091429773 < 0 id:0
000091429778 > PLAY 0 1
000091429782 < 24
000091429788 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16050 left_co
eff:16050 deadband:0 center:0
000091429792 < 0 id:3
000091429795 > PLAY 3 1
000091429798 < 24
000091439889 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-4951 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091439916 < 0 id:0
000091439921 > PLAY 0 1
000091439927 < 24
000091439942 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16050 left_co
eff:16050 deadband:0 center:0
000091439946 < 0 id:3
000091439949 > PLAY 3 1
000091439952 < 24
000091450039 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-2798 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091450063 < 0 id:0
000091450068 > PLAY 0 1
000091450072 < 24
000091450078 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0
000091450082 < 0 id:3
000091450085 > PLAY 3 1
000091450088 < 24
000091460179 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-1891 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091460205 < 0 id:0
000091460210 > PLAY 0 1
000091460215 < 24
000091460221 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0
000091460225 < 0 id:3
000091460228 > PLAY 3 1
000091460232 < 24
000091470324 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-1891 attack_length:0 attack_level:0 fade_length:0 fade_leve
l:0
000091470350 < 0 id:0
000091470355 > PLAY 0 1
000091470360 < 24
000091470365 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0
000091470369 < 0 id:3
000091470372 > PLAY 3 1
000091470376 < 24
000091480460 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-518 attack_length:0 attack_level:0 fade_length:0 fade_level
:0
000091480484 < 0 id:0
000091480489 > PLAY 0 1
000091480493 < 24
000091480499 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0
000091480503 < 0 id:3
000091480506 > PLAY 3 1
000091480509 < 24
000091490598 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:-518 attack_length:0 attack_level:0 fade_length:0 fade_level
:0
000091490622 < 0 id:0
000091490627 > PLAY 0 1
000091490632 < 24
000091490638 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0
000091490659 < 0 id:3
000091490665 > PLAY 3 1
000091490668 < 24
000091500757 > UPLOAD id:0 dir:16384 length:0 delay:0 type:CONSTANT level:0 attack_length:0 attack_level:0 fade_length:0 fade_level:0
000091500783 < 0 id:0
000091500788 > PLAY 0 1
000091500793 < 24
000091500799 > UPLOAD id:3 dir:0 length:0 delay:0 type:FRICTION right_saturation:65535 left_saturation:65535 right_coeff:16046 left_co
eff:16046 deadband:0 center:0

[kevenwyld]

Just to say that I did, I spun up a windows machine (hardware, not a vm) and tested the game with my existing beamng profile. Everything works as expected and I do not experience this issue on windows at all. I also don't see the error about defaulting to 65536 steps.

The FFB experience in windows otherwise feels the same, apart from not reacting unexpectedly when reaching soft lock.

[kevenwyld]

OK... so I switched from Proton Experimental to Proton-7.2-GE-2 (https://github.com/GloriousEggroll/proton-ge-custom) for beamng and the "sticking" issue from my video went away. I switched because of another issue where controller input stopped working entirely on the upstream 7.x proton branch, but that has nothing to do with this driver as it was all input including my other non-thrustmaster devices.

I still get the Steering wheel drivers didn't provide any FFB resolution information. Defaulting to 65536 steps warning in the game console but it doesn't seem to impact anything.

So I suppose you can close this if you want. It's not really the clear "hey here's the issue right here!" solution but probably not something worth your time looking into either.

[Kimplul]

Thanks for the heads up, I wouldn't necessarily be surprised if the issue was with my driver and the different Proton version just steps around the issue or something along those lines. Still haven't ordered new pedals, I'm kind of thinking of just buying a T248 which comes with pedals that should be compatible with the T300, would cost a bit more but I'd like to try seeing if I can maybe get more wheels to work under Linux.

Anycase, thank you very much for your help, I'll close this for now but I'll keep an eye out for similar issues and I'll update this thread in case I find something relevant.

[kevenwyld]

@Kimplul I've been experiencing this again lately and was wondering if you'd be able to test with your new hardware assuming you have it working now. If you can recreate the problem maybe we could reopen this case and do some more troubleshooting?

Beamng+proton is a weird and unreliable combination in a lot of ways but in this case I do think it has something to do with this driver and I'd really like to help you figure it out if I can.

I have purchased a new t300 base (not related to this problem, the paddles stopped working on my old one) as well as a new wheel (sparco R383 Mod), I've updated the driver to the latest one you have available with the new name, and it's still very consistent when enabling soft lock in game, or sometimes even without that on certain vehicle models. It seems to be much worse the higher I set the FFB "strength". And it is ONLY when turning right. That last one is really strange.

Anyway let me know if you think you might have time to reopen this and take a look.

Thanks!

[Kimplul]

Anyway let me know if you think you might have time to reopen this and take a look.

Sure. I'm again doing an internship in another city and haven't been home for a little while, but I'll probably take a couple weekends and go fetch the mail etc. and I'll see if I can figure something out. Development will obviously be slow during the summer, sorry in advance.

Beamng+proton is a weird and unreliable combination in a lot of ways but in this case I do think it has something to do with this driver and I'd really like to help you figure it out if I can.

Could you specify which versions of proton and which cars cause this issue without soft lock?

Steering wheel drivers didn't provide any FFB resolution information. Defaulting to 65536 steps

I wonder if this is related to https://docs.microsoft.com/en-us/windows/win32/api/dinputd/ns-dinputd-diffobjectattributes? I'll need to check out what keys Thrustmaster set in the registry.

[kevenwyld]

I use proton 6.3-8 currently. FFB doesn't work at all in many games on 7.x and experimental branches right now. there are lots of reports of issues with it on the ValveSoftware/Proton game specific github issues, but that has nothing to do with this driver.

With soft lock off I notice sticking (though not quite as severe) with the following cars as long as FFB is above 400:

I-Series Rally - Gravel (M)
Bolide 390 GT Group 4 - Gravel (M)

When driving around on flat ground or trying to drift a little it feels really jumpy and will sometimes get into that state I shared videos of above. Usually if you are near or past where the vehicle's simulated lock is. It finds it's way out of it though eventually but there's a lot of snapping back and forth. Unlike turning left where everything is smooth and fine and steering returns to center like you'd expect IRL.

With soft lock on I notice it on every vehicle and if it gets into the state like the videos it will not come out of it until you force the wheel back to center with your hands.

Here are my FFB/steering settings in beamng, I do not use a compatibility curve.:

I'm not currently using oversteer at all, so the driver is set entirely to it's defaults. I did try timer_msecs=3 as suggested in the readme for some games but it didn't seem to make any difference.

wonder if this is related to...

Ah interesting. If I manage to get a windows box going again soon I'll take a look

In related news I read today on the beamng forums that a release of beamng with native Linux binaries is planned next week. So that will definitely change things, hopefully for the better.

I hope your internship goes well!

[kevenwyld]

Dropping this here in case someone else needs it. I plan to test it out with my t300rs when I get the chance and I will report back. This description sounds very much like what I've been experiencing. https://www.beamng.com/threads/linux-multiple-distros-force-feedback-jerks-to-opposite-direction-g920.81804/

EDIT: This resolves the main issue on at least the few vehicles I have been able to test so far. The impact is immediately noticeable by adding the following patch from the link above:

--- hydros.old.lua      2021-09-11 02:51:34.193807964 -0400
+++ hydros.lua  2021-09-11 02:52:51.473808335 -0400
@@ -146,6 +146,8 @@
 
       -- figure out the fake number that the drivers want to hear, in order to really output the desired torque at the wheel
       local newForceAtDriver = responseCorrected and getDriverForce(forceAtWheel) or forceAtWheel
+      -- LINUX: For some reason going at positive limit causes a wrap around and jerks the steering to the opposite direction. Clamping to the limit with a small amount removed.
+      newForceAtDriver = sign(newForceAtDriver) * min(abs(newForceAtDriver), M.curForceLimit - 0.001)
 
       -- send force only if the driver will see any difference (i.e. skip when still in the same driver ffb quantum step as last time)
       local newForceQuantum = math.floor(newForceAtDriver * invFFstep)

For me the file is located at .local/share/Steam/steamapps/common/BeamNG.drive/lua/vehicle/hydros.lua

This unfortunately does not resolve the issue when using softlock. I suspect the answer is in the lua script section directly below where this is added but I'll need to bang my head against it for a bit.

Anyway, once again I'm not sure what to do here. I don't know if this is a driver problem that we are working around, or a beamng problem.

[Kimplul]

Yeah, stuff like this tends to be pretty complicated, unfortunately. I'm still planning on taking a look at the vehicles myself when I get the time. Just because the issue can be worked around in a script doesn't necessarily mean that the driver (or the FFB subsystem itself) is correct, at least considering that the patch seems to be unnecessary on Windows. Same goes for the softlock part.

Again, thank you very much for all the work you've done so far.

[berarma]

I've seen a very similar problem in new-lg4ff. I had to redefine the fixp_sin16 macro because it had an error where it would return incorrect values in the limits.

Please, take a look at the way I define fixp_sin16 at the start of the new_lg4ff.c file and see if that fixes your problem.

I opened a bug in the Linux tracker but it didn't got any attention. Sorry, I can't provide links right now, I'm on the phone.

[Kimplul]

Pretty sure I have it already copied:

hid-tmff2/hid-tmff2.h

Line 41 in 162a1f6

#define fixp_sin16(v) (((v % 360) > 180) ?\

Of course, could be that there's some similar issue somewhere else in my codebase.

[berarma]

Pretty sure I have it already copied:

hid-tmff2/hid-tmff2.h

Line 41 in 162a1f6

#define fixp_sin16(v) (((v % 360) > 180) ?\

Of course, could be that there's some similar issue somewhere else in my codebase.

True. I couldn't browse the code properly to see. It's a very similar issue though. It could be the same bug in some other macro or piece of code.

[WhiteHusky]

Anyways. I sorta recall how I found that bug. The D-Series Pre-Runner is a vehicle I had issues with and if you turned right enough and gave enough throttle input, it'd throw the wheel to the right and full-lock it.

If you pull up the FFB debug app and watch—it would happen when it's trying to give it all the power to push left, but as we've seen it instead sends it to the right.

Kinda wished I noted down how I got to that conclusion, but I'm sure I just opened VSCode on Beam's Lua folder and looked at anything FFB related, dropped console logs, and eventually found the gremlin to kill.

[WhiteHusky]

Got the T300RS in and it seems to work perfectly with the Linux build of BeamNG.Drive. I can't get Beam to work in Proton at the moment due to moving stuff around, but if you're having issues with the wheel with the Proton version might as well try it in the Linux build.

Of course it won't fix the Proton issue but at least you can get our favorite soft body driving sim fix.

[kevenwyld]

@WhiteHusky thanks, yeah I've tried the t300rs with the Linux binaries and it does work well. I haven't been able to recreate this issue using them. Unfortunately, for me at least, the Linux binaries are pretty buggy and slow in other ways so I'm not comfortable saying it isn't there. It's really pretty much barely playable even with the various RADV optimizations suggested in the Linux thread. Proton using beamng's experimental vulkan mode is still quite a bit better for my setup.

[kevenwyld]

Just a quick update. This issue is still present in BeamNG.drive 0.27 however my earlier comment about updating hydros.lua still works around it for me.

The sudden reversal of FFB is noticeable on more cars in the latest version. In the Vivace Rally - Gravel I can recreate it by simply turning right on flat ground while pressing and releasing the throttle repeatedly. It does not happen when turning left. I have no idea why...