[SDL2] Adding input and FFB support for Logitech G29(PS3) on hidapi

[Kethen]

Description

These changes enable the Logitech G29 wheel to run on hidapi with both SDL_Joystick and SDL_Haptic interfaces.

While it is already possible to use the wheel on Linux in WINE + SDL2 thanks to the in-tree evdev driver as well as new-lg4ff, these set of changes allow the G29 to be used with WINE under MacOS and FreeBSD

These wheels should also be supported, but I can only test them from G29's compat modes: G27, G25, DFGT, DFP, DFEX

Haptic and led support are ported from https://github.com/berarma/new-lg4ff so giving @berarma a ping here

Companion test program for testing SDL_Joystick input events, changing wheel compat mode and testing SDL_Haptic calls

https://github.com/Kethen/sdl_lg4ff_util/

Help wanted for this pull request

• Makefile.os2, Makefile.w32, VisualC project files
• More testing and code review

Help wanted for future pull requests

• Support for G923 and other wheels that runs on the same ffb protocol but cannot be emualted by my G29
• Shifter input, it might already work but I don't own one as of writing so I can't test that

Existing Issue(s)

#6540

[slouken]

Can you retarget this PR for SDL3?

[Kethen]

Can you retarget this PR for SDL3?

#11598

[sezero]

I don't know whether or not this will be accepted into SDL2 branch, but
here is a patch that adds new files to Makefile.os2 / Makefile.w32, and
fixes C89 issues, fixes some warnings, and missing end-of-file issues.
(a few bits taken from SDL3 version. Also note the signedness issue in
HIDAPI_DriverLg4ff_UpdateDevice() is also present in the SDL3 version.)
patch.txt

One issue is SDL_hidapihaptic_lg4ff.c does libc function calls sprintf,
abs and llabs, and especially windows can be built without libc support.
For that, sprintf can be replaced with SDL_snprintf, which I did in the
patch like you did in the SDL3 version. abs() with SDL_abs, but if you
want the compiler to optimize it, you can add a static inline for it in
the lg4ff source. There is no SDL_llabs though: either it can be added
as a new SDL api call, or llabs can be added to lg4ff source as a static
inline helper so that the compiler can optimize it. (Note: the abs and
llabs() issue of directly calling into libc seems to present in the SDL3
version too.)

[Kethen]

@sezero Thank you so much for the patch, can I ask for a version with git format-patch so that I can include your work as your commits?

As for whether this will be accepted or not, I'm unsure, and there seems to be a sentiment to use sdl2-compat in some linux distros eg. https://fedoraproject.org/wiki/Changes/SDL2onSDL3

[sezero]

@sezero Thank you so much for the patch, can I ask for a version with git format-patch so that I can include your work as your commits?

There you go: 0001.patch.txt

Note that the abs() and llabs() issue is still there. (SDL_abs() is the worst thing added to SDL api...)
(Maybe you should add abs32() and abs64() static inlines in there and use them instead.)

[berarma]

Implementing a hardware driver inside SDL is something I would never expect. I'd say it's a bad idea but who knows, maybe I'm old fashioned.

I would have thought porting the driver would be a better idea but maybe it's not possible.

[Kethen]

Hey @berarma , thanks for looking at and commenting on this! Please also see #11598 (comment) , as the author of new-lg4ff, you can decide whether code ported from your driver can be part of SDL or not

Implementing a hardware driver inside SDL is something I would never expect. I'd say it's a bad idea but who knows, maybe I'm old fashioned.

I would have thought porting the driver would be a better idea but maybe it's not possible.

On open platforms like FreeBSD, I'd agree, someone well versed in FreeBSD development should be able to develop/port drivers to FreeBSD evdev, yielding a better performing driver, even when a userspace driver might be "good enough"

On other platforms however, it's not always possible

On Android, how the kernel is compiled is up to device manufacturers (and they orphan their kernels way way too often), the Paddleboat API does not have any feedback support beyond vibration motors, there's sure no HAL implemented for more complicated evdev FFB; However it is possible to get raw usb access

On Apple operating systems, they introduced GCRacingWheel in 2022, but it lacks force feedback currently and which wheel they support is entirely up to them; To support custom devices on a per application baisis, they provide IOHIDManager and IOKit

SDL's various hidapi controller implementations can be used in these situations

[slouken]

Yeah, we'll need official permission from @berarma to relicense code based on their work under the Zlib license for SDL.

[berarma]

Yeah, we'll need official permission from @berarma to relicense code based on their work under the Zlib license for SDL.

My work is based on the Linux lg4ff module. I added code to implement more effects other than the constant effect and some tweaking features. I'm not sure I'm in a position to decide this.

[Kethen]

Then I believe yet another person to ping would be @mungewell, going by the header of hid-lg4ff.c