This sounds like a standard problem with wrongly choosing a signed or unsigned integer, which simply gets overflown.
example: a) int16_t, 16bit, -32767 to 32767 (0 center)
b) uint16_t, 16bit, 0 to 65535 (32768 center)
This is defined in the HID, or firmware of the device. Usually for wheel controllers, the steering axis is a signed integer, for example (a), where the raw value of 0 is a wheel center and this is used to calculate the FFB. In that case, bits 0 to 14 are the value, while the last bit15 is a sign. Giving this variable a value of 32768 will cause it to overflow and give a result of -32767. The same goes for an FFB magnitude value, which if not defined correctly may cause the same issue. The LFS is simply reading whatever is reported by the device in HID descriptor.
To check this, I would suggest you try one of the following programs capable of reading raw values from USB joysticks or wheels: DIView, DXTweak2
The best would be: WheelCheck which can generate FFB effects as well.
See attached pictures of DXTweak. For some reason, I got device names reversed while printscreen. My DIY Arduino wheel is -32k to 32k and Thrustmaster wheel is 0 65535 in X axis. Both wheels are working normally in LFS with the correct FFB.