Forcefeeback Control

[NeighborDva]

Hello.

I wanted to use t500rs product at first because I wanted to control force feedback (handle control) as shown in the image above, but I'm looking for another product because it's not supported by the driver you developed.

I'm thinking of using one of the products supported by this driver, t300rs gt, do you have any advice on controlling the handle with force feedback?

https://github.com/kuriatsu/ros-g29-force-feedback
Referring to the link above, it seems to be based on linux/input.h. Can Trustmaster's products also control the handle with force feedback based on the library?

[Kimplul]

I'm thinking of using one of the products supported by this driver, t300rs gt, do you have any advice on controlling the handle with force feedback?

Interesting idea, I guess my first reaction would just be to use a constant effect combined with a damper, presumably the damper effect would stop the wheel from overrotating once the constant effect is removed. Then just monitor the input and adjust the direction of the constant force. Assuming you mean that you want to write it on your own?

Maybe worth noting that the driver collects up effects and sends out the 'final' result to the wheel every n milliseconds (the timing can be changed by the driver parameter timer_msecs, see bottom of README), so lots of very small direction changes in a very small amount of time might not behave quite as expected.

Referring to the link above, it seems to be based on linux/input.h. Can Trustmaster's products also control the handle with force feedback based on the library?

The ioctl FFB "API" is the same for all wheels supported by linux, so shouldn't be a huge issue, but looking at the code it seems that it has some assumptions about the wheel which might not match with the T300, mainly like motor strength or something along those lines. Some forking may be required. Personally, I would probably just use SDL instead of ioctl directly, but I don't think it should have an effect on functionality.

[NeighborDva]

Thank you for your response and advice.

In order to perfectly use linux/input.h or sdl, do I have to use the product(t300rs gt, t248) supported by the driver you developed?

I have additional questions.

Is there any difference between Logitech products and how to obtain Raw data?

[Kimplul]

Sorry, GitHub doesn't send out email notifications when you edit your comments so I completely missed your questions. I'm sure you've figured things out by now, but I'll just post answer some short answers for future reference.

In order to perfectly use linux/input.h or sdl, do I have to use the product(t300rs gt, t248) supported by the driver you developed?

Logitech devices are at least as well supported by SDL as the T300/T248, particularly with https://github.com/berarma/new-lg4ff. There are apparently other drivers being developed for other manufacturers, but I don't know what their status is.

Is there any difference between Logitech products and how to obtain Raw data?

Depends on what you mean by raw data. If you're just referring to getting input like wheel button states, rotation, etc, then the answer is more or less no difference, all input can be read as generic buttons or axes on a joystick via SDL for example. The pedal mapping can be different, i.e. the gas pedal on a T3PA could potentially be mapped to a different software axis (Rz, for example) than the gas pedal on a Logitech product, so if you want to support both wheels you would likely need some kind of calibration routine, like asking the user to press down on the gas pedal and checking which axis is changing correspondingly.

If you mean something more low-level, like reading raw USB traffic, then both Logitech and Thrustmaster wheels are HID devices so if you can parse HID date, you can parse wheel input, but it's not 1:1 identical as far as I'm aware.