berarma
commented
9 months ago What would be needed to be done for implementing FF_INERTIA? I am making myself aware of how the driver works and am interested in contributing addition of Inertia effects. However what's not clear to me at the moment is which parts would need to be altered to get it working. I am also interested in learning this so I can potentially add it to the Fanatec HID Driver that is available, which appears to have similar structure (unsurprisingly).
First, we would have to know how this effect should work. Since the firmware in my wheel doesn't support it, once implemented I wouldn't be able to test that it works the way it should. I guess it would add resistance to sudden reactions on the wheel, like when going from still to rotating very fast, or a sudden change in the direction of rotation. As if the wheel itself had a lot of weight.
It would be good to have some reference game which uses this effect well. Do you know some game using this effect where it's clearly missed?
Some games avoid the use of this kind of prepared effects and simply implement them on their own using constant forces.
presumably the following would have to be done; (the following are all changes in lg4ff as opposed to lg2ff, lg3ff etc.)
* change in lg4ff_wheel_effects array * change in lg4ff_update_slots and lg4ff_init_slots * potential addition in lg4ff_effect_envelope (but I guess not given it is a condition effect) * declaration and definition of lg4ff_calculate_inertia function and alteration in lg4ff_timerWould anything else have to be added?
This kind of effect doesn't use an envelope.
I avoided implementing condition effects because I would need reading and calculating the position and motion of the wheel. Since the firmware already implements most of these effects I preferred using the firmware implementation.
So one gap that should be filled is reading the position from the packets the wheel sends, taking the position of the wheel and calculate the velocity at every given time. That's how I think it should be done since I don't think we can call ioctl() functions from a driver. And I don't know if there would be some other way of reading this information without accessing the USB packets directly. I haven't looked into this.
I also have not understood exactly how this interfaces with the write() calls from the kernel. I originally assumed it was done using ioctl, but there are no mentions of ioctl in the driver source (that I can find). It is not clear to me how the relevant functions are called in the driver given specific written bit sequences from write() calls in e.g. evdev.
You can trace the source code from the write/ioctl functions down to the hid-lgff and then the hid-lg4ff code. Both write() and ioctl() are user-land functions, abstractions of the hardware, while the driver uses internal kernel functions at a lower level closer to the hardware.
Also, where can I find information on the exact data passed in the HID Output reports? I cannot get them to appear in e.g. hid-tools/hid-record report printing (it only gives me HID Input reports) although the general structure is presented in the hid-decode output. Furthermore whilst the output report structure appears to offer 16 bytes of data, I only see the driver affecting 0-7 (in cases of lg4ff_send_cmd).
For Logitech wheels there's this: https://opensource.logitech.com/wiki/Technical_Information/
Any information would be of great help (and interest!).
I would advice on evaluating the benefits of having the inertia effect against the work and complexity of its implementation. Many games don't use it, some might use it superfluously, and in low-powered wheels like the Logitech ones, more effects playing at the same time means more saturation (effects get lost).
For the Fanatec wheels, I'm a bit surprised they don't implement these effects in firmware. Maybe it's just that there's no information on how to play these effects through firmware. If that was the case, reverse-engineering a way to use the firmware could be a better investment of time.
Ask for anything you need.
wegreenall
What would be needed to be done for implementing FF_INERTIA? I am making myself aware of how the driver works and am interested in contributing addition of Inertia effects. However what's not clear to me at the moment is which parts would need to be altered to get it working. I am also interested in learning this so I can potentially add it to the Fanatec HID Driver that is available, which appears to have similar structure (unsurprisingly).
presumably the following would have to be done; (the following are all changes in lg4ff as opposed to lg2ff, lg3ff etc.)
Would anything else have to be added?
I also have not understood exactly how this interfaces with the write() calls from the kernel. I originally assumed it was done using ioctl, but there are no mentions of ioctl in the driver source (that I can find). It is not clear to me how the relevant functions are called in the driver given specific written bit sequences from write() calls in e.g. evdev.
Also, where can I find information on the exact data passed in the HID Output reports? I cannot get them to appear in e.g. hid-tools/hid-record report printing (it only gives me HID Input reports) although the general structure is presented in the hid-decode output. Furthermore whilst the output report structure appears to offer 16 bytes of data, I only see the driver affecting 0-7 (in cases of lg4ff_send_cmd).
Any information would be of great help (and interest!).