This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• ugly work-around to play effects againts a X-axis only direction (SDL2-haptic-x-force.patch, text/plain, 2016-10-04 19:58:46 +0000, 1639 bytes)
• Make it possible to play effects against the first axis only. (SDL2-haptic-first-axis.patch, text/plain, 2017-08-30 12:04:58 +0000, 1502 bytes)
• Linux implementation and doc (first_axis.patch, text/plain, 2020-03-17 12:32:56 +0000, 1323 bytes)
• better doc and name (steering_axis_doc.diff, text/plain, 2020-05-04 17:08:08 +0000, 3174 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2016-10-04 19:58:46 +0000, Mathieu Laurendeau wrote:

Created attachment 2574
ugly work-around to play effects againts a X-axis only direction

Consider a device supporting effects on multiple axes.
There's currently no way to play effects against a single-axis direction.

A device supporting effects against X and Y may not allow to play effects with a two-axis direction coordinate, even if one of the coordinates is null.

My current (ugly) work around for this is to add a direction type SDL_HAPTIC_X_FORCE to play effects against a X-axis only direction (patch attached).

On 2017-08-30 12:03:50 +0000, Mathieu Laurendeau wrote:

This issue impacted two GIMX users using the following wheels:

• Leo Bodnar SimSteering force feedback wheel
• Accuforce direct drive wheel

Playing constant/spring/damper effects against a X-axis direction worked well for the first wheel, but not for the second one.

A better strategy seems to play the effects against the first axis reported by the DirectInput enumeration.

This strategy also works with Logitech wheels (at least the DFGT).

On 2017-08-30 12:04:58 +0000, Mathieu Laurendeau wrote:

Created attachment 2901
Make it possible to play effects against the first axis only.

On 2018-11-18 20:30:01 +0000, Mathieu Laurendeau wrote:

It's been more than a year that I have the latest patch (playing effects against the first axis only) in the GIMX software. It's being used by thousands of people, mostly for adapting their FFB wheel to the PS4. I had no report that proves this strategy to be wrong.

On 2020-03-16 20:30:00 +0000, Sam Lantinga wrote:

This patch is added, thanks!
https://hg.libsdl.org/SDL/rev/701fe6486077

What would the appropriate test be to add to testhaptic.c?

On 2020-03-17 12:32:56 +0000, Mathieu Eyraud wrote:

Created attachment 4266
Linux implementation and doc

Added Linux implementation, otherwise you get "Unsupported direction type" error.
Added documentation to explain why one would use SDL_HAPTIC_FIRST_AXIS.

On 2020-03-17 21:36:05 +0000, Sam Lantinga wrote:

Added, thanks!
https://hg.libsdl.org/SDL/rev/f7fc52b64177

On 2020-04-25 13:05:14 +0000, Mathieu Laurendeau wrote:

Hello,

Thanks for adding the patch!

The added documentation is however confusing. DirectInput enumeration can return the force feedback axes in any order. If enumeration provides {X, Y, Z} then SDL_HAPTIC_FIRST_AXIS is equivalent to a direction X with SDL_HAPTIC_CARTESIAN. But if enumeration provides {Y, X, Z}, then SDL_HAPTIC_FIRST_AXIS is equivalent to a direction Y with SDL_HAPTIC_CARTESIAN.

Also, this direction type does not seem relevant for the Linux implementation since there is no enumeration of the force feedback axes. Getting an "Unsupported direction type" error looks fine. The documentation can state that the direction type is not supported in all implementations and that the error should be catched.

On 2020-04-25 19:21:59 +0000, Mathieu Eyraud wrote:

(In reply to Mathieu Laurendeau from comment # 7)

The added documentation is however confusing. DirectInput enumeration can
return the force feedback axes in any order.

Maybe the documentation could be improved, but steering wheel only have one physical axis, so X, Y or Z doesn't really matter.

Also, this direction type does not seem relevant for the Linux
implementation since there is no enumeration of the force feedback axes.
Getting an "Unsupported direction type" error looks fine.

The workaround is not needed on Linux but SDL is meant to make multiplatform development easier. SDL_HAPTIC_FIRST_AXIS should have the same behavior on all platforms.

On 2020-04-27 22:22:19 +0000, Mathieu Laurendeau wrote:

I see no reason why a device containing a steering wheel should only have a single force feedback axis.

The effective direction for SDL_HAPTIC_FIRST_AXIS depends on the device driver, which means it may not be the same direction depending on the operating system.

In my opinion the part of the documentation starting with "Using SDL_HAPTIC_FIRST_AXIS is equivalent to :" is confusing and should be removed.

Lastly, as far as I know this patch was only tested on Windows. It does not makes sense to add it for other operating systems unless it is proven to actually provide the same behavior on all operating systems.

On 2020-04-28 13:46:17 +0000, Mathieu Eyraud wrote:

I see how the documentation is confusing. I think that the choice of the axis is an implementation detail. The documentation should state the goal of this value, so I propose this wording:

"Use this value to play an effect on the steering wheel axis. This provides
 better compatibility across platforms and devices as SDL will guess the 
 correct axis."

Value could even be renamed 'SDL_HAPTIC_STEERING_AXIS'.

For Linux, sending an effect on the X axis with a Logitech wheel works. Others brands don't have driver for Linux as far as I know.

On 2020-05-02 21:15:22 +0000, Mathieu Laurendeau wrote:

I agree with the proposed wording and with renaming the direction type!

On 2020-05-02 21:55:53 +0000, Sam Lantinga wrote:

Sounds good, can you guys provide a patch with the proposed change?

On 2020-05-04 17:08:08 +0000, Mathieu Eyraud wrote:

Created attachment 4328
better doc and name

Patch for new documentation and name.

On 2020-05-04 20:18:16 +0000, Sam Lantinga wrote:

Okay, this patch is in, thanks!
https://hg.libsdl.org/SDL/rev/a359f4f93439