Force Feedback with PID Wheel

Question

Force Feedback with PID Wheel

Spacefreak18 opened this issue 2 years ago · 3 comments

Hopefully that's a good title for this topic, and this seems to be the place to be for general linux force feedback assistance.

I have an SimXperience Accuforce V2 wheel. I wasn't going to entertain the idea of trying to sim race on Linux because it seemed after i made the switch from Logitech to Thrustmaster, and added devices to my rig like a Tachometer and bass shakers, it was just going to be impossible. But i was quite surprised when i found that all the feedback effects of the Accuforce wheel were supported by the Linux kernel. I also started a project where I backwards engineered the revburner Tachometer board, and I'm in the process of writing a cross-platform replacement for SimHub.

Anyway, so now that I can actually get effects to work through wine and into SDL, it's still not working right in-game.

There's still a lot of issues, so in my head i'm ordering them like this:

After about a minute of playing effects in Assetto Corsa or RFactor 2, all effects stop. This does not seem to happen when I'm testing with ForceTest.exe. I saved the "effect script" using logging in ffbwrap, and i hope to replay it in the coming days to see if it's something specific about the way the effects are being played. I noticed i get "output queue full" in dmesg. I enabled throttling in ffbwrap with seemingly no difference.
Those effects seem to be "excessive". But when i get the previous problems fixed, i'll have to play around with gain settings.
I also may be missing rumble effects in-game. I have to boot the game up in Windows again to be sure.
When I plug the device in, it does say something like "this device has an unsupported autocenter method".
The implement error, that is in this thread is spamming dmesg, so it's hard to find something useful for the above issues, but I don't think there is anyway.

I also noticed that SDL_DYNAMIC_API wasn't behaving the way I thought, and Steam seems to be using the 64 bit SDL installed by debian.

Answer 1 · 2022-09-03T15:37:21.000Z

Does anyone have a command i can use with tshark to captue just the HID reports for the haptic effects sent to the wheel? Or some other tool to capture the raw HID reports?

Answer 2 · 2022-09-05T05:56:44.000Z

For item 1, i noticed a lot of "output queue full" messages in dmesg. I enabled --throttling and set the timeout for 100ms with seemingly no difference.

Does anyone have insight as to the background for those settings?

Also when i run an ffbwrap log through ffplay, from a session that has been capture from a "throttled" session, is that ffplay back also throttled?

Here is the link to the log generated by ffbwrap.

Answer 3 · 2022-09-06T14:28:49.000Z

Most options in ffbwrap are workarounds to issues that existed some time ago. Proton had a lot of issues that prevented working FFB in wheels, and there was also a kernel bug that caused issues.

Those workarounds shouldn't be needed anymore on current Proton and kernel versions. But if you find you need them they might reveal some issue, and depending on the option used to fix it we could know something more about the underlying problem.

I would start by identifying which workarounds are useful and for what. I see you have several of them enabled in your log. Let's see which ones are really useful and what do they fix. I can help you interpret the results.

The log outputs the calls as the game/app does them, no throttling is logged and thus replaying has no throttling unless you run ffbplay itself through ffbwrap. You can see in the logs what the game/app is doing, but not what ffbwrap is doing.

Maybe you could run ffbwrap through ffbwrap and have two logs, one for the game/app and one for the first instance of ffbwrap itself. I haven't tried that but it might work.

The way throttling is implemented, it still can send bursts of effect updates. It doesn't allow more than one update every 100ms (the throttling time) for every effect but it allows any amount of effects updating. So if you have 16 effects loaded it could still send 16 effect updates very fast. I think this shouldn't be an issue since the kernel has an internal queue that should be big enough for updating the few effects that we see used in the log.