Commit Graph

31 Commits

Author SHA1 Message Date
pionere 60deadba59 re-use return value of SDL_SetError/WIN_SetErrorFromHRESULT/SDL_OutOfMemory 2022-01-28 20:40:19 -05:00
Sam Lantinga 120c76c84b Updated copyright for 2022 2022-01-03 09:40:21 -08:00
Cameron Gutman 6b64c47b69 haptics: Enumerate XInput/DInput joysticks after haptic init
Since the haptic subsystem is usually initialized after the joystick subsystem,
the initial calls to HapticMaybeAddDevice() from inside SDL_JoystickInit() will
arrive too early to be handled by the haptic subsystem. We need to add those
haptic devices for those already present joysticks ourselves.
2021-11-09 23:46:34 -06:00
Cameron Gutman 715e7bda22 haptic: Don't enumerate joysticks if the joystick subsystem is active
The joystick subsystem has complex precedence logic to deal multiple competing
backends like XInput, RawInput, and WGI. Let it fire the MaybeAdd callbacks
for joystick devices, since it knows which backend will end up managing them.

This resolves a situation where the RawInput joystick backend would take
control of an XInput device but the XInput haptic backend would still create
a haptic device. Since the XInput joystick backend didn't own the underlying
joystick device, we'd end up with an orphaned haptic device that didn't work
with SDL_HapticOpenFromJoystick() on the associated joystick device.
2021-11-09 01:43:44 -06:00
Dimitriy Ryazantcev a6da2fbf73 Rename haptic methods to avoid confusion with joystick:
`SDL_DINPUT_MaybeAddDevice`->`SDL_DINPUT_HapticMaybeAddDevice`
`SDL_DINPUT_MaybeRemoveDevice`->`SDL_DINPUT_HapticMaybeRemoveDevice`
`SDL_XINPUT_MaybeAddDevice`->`SDL_XINPUT_HapticMaybeAddDevice`
`SDL_XINPUT_MaybeRemoveDevice`->`SDL_XINPUT_HapticMaybeRemoveDevice`
2021-06-10 16:41:09 -07:00
Dimitriy Ryazantcev 73dc68a7ae Simplify and cleanup DirectInput joystick backend code:
- Do not call IDirectInputDevice8_QueryInterface(device, &IID_IDirectInputDevice8,...) on DIRECTINPUTDEVICE8 device
- Get joystick VendorID and ProductID via IDirectInputDevice8_GetProperty(.., DIPROP_VIDPID, ..) call instead of messing with DIDEVICEINSTANCE.guidProduct
- Normalize HID device interface path to upper case for stable operation of XInput check
- Remove useless RawInput calls in SDL_IsXInputDevice() - just check for "IG_" string in HID device interface path that we already have

There shouldn't be any observable behavior changes.
2021-06-10 16:41:09 -07:00
Sam Lantinga 9130f7c377 Updated copyright for 2021 2021-01-02 10:25:38 -08:00
Sam Lantinga cb36189692 Fixed bug 5235 - All internal sources should include SDL_assert.h
Ryan C. Gordon

We should really stick this in SDL_internal.h or something so it's always available.
2020-12-09 07:16:22 -08:00
stfx b162629546 cmake: Fix building with -DSDL_HAPTIC=Off 2020-07-08 17:28:34 +02:00
stfx efe0935904 Fix compile without DIRECTX 2020-06-15 10:31:16 +02:00
Ryan C. Gordon 68777406e5 windows: Fix calls to CoCreateInstance() so last parameter is a LPVOID *. 2020-05-20 16:58:33 -04:00
Sam Lantinga 65ad45340d Improvement for bug 3446 - The haptic API does not allow to select the direction axes
meyraud705

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.
2020-05-04 13:17:43 -07:00
Sam Lantinga 7379991778 Fixed bug 3446 - The haptic API does not allow to select the direction axes
Mathieu Laurendeau

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).

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).

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.
2020-03-16 13:28:38 -07:00
Sam Lantinga a8780c6a28 Updated copyright date for 2020 2020-01-16 20:49:25 -08:00
Sam Lantinga 5e13087b0f Updated copyright for 2019 2019-01-04 22:01:14 -08:00
Sam Lantinga f1bc1c1274 Fixed crash trying to open HIDAPI controller as a haptics device on Windows 2018-08-22 17:44:28 -07:00
Sam Lantinga e3cc5b2c6b Updated copyright for 2018 2018-01-03 10:03:25 -08:00
Sam Lantinga 0d011ec66d Renaming of guard header names to quiet -Wreserved-id-macro 2017-08-28 00:22:23 -07:00
Ryan C. Gordon d96419c93f xinput: use the full range of the haptic motors (thanks, Trent!).
XInput goes from 0 to 64k; we were feeding it values in the range of 0 to 32k.

Fixes Bugzilla #3002.
2017-06-21 01:22:00 -04:00
Ryan C. Gordon 70c0400b12 windows: Try to unify all the GUID comparison code into a core helper function.
There are likely several more I missed.
2017-02-13 17:00:46 -05:00
Sam Lantinga dd007e3fe7 Fixed bug 3561 - Re-acquire device before playing effects if needed.
Mathieu Laurendeau

Check the result of IDirectInputEffect_SetParameters and re-acquire the device to solve concurrency issues.
2017-01-18 11:58:16 -08:00
Sam Lantinga 45b774e3f7 Updated copyright for 2017 2017-01-01 18:33:28 -08:00
Philipp Wiesemann 97aa577589 Fixed empty parameter list in signatures of internal functions. 2016-11-16 22:08:51 +01:00
Sam Lantinga 27d4f09929 Implemented SDL_GetHintBoolean() to make it easier to check boolean hints 2016-10-07 23:40:44 -07:00
Sam Lantinga a21a227a87 Fixed bug 3021 - HapticOpenFromJoystick() problems
Joe Thompson

With Direct Input device (MOMO Steering Wheel w/FF)
with SDL 2.0.3,
SDL_HapticOpenFromJoystick() would fail. (Can't set exclusive mode)
Now with 2.0.4 rc1,
SDL_HapticOpenFromJoystick() succeeds but the the returned SDL_Haptic* cannot be used. Calls to SDL_HapticNewEffect() fail with "Haptic error Unable to create effect"

If SDL_HapticOpen() is used instead of HapticOpenFromJoystick(), the device is usable. Calls to HapticNewEffect() succeed with the exact same parameters as the previous failing call.

I have attached a proposed patch for this issue.

When using SDL_HapticOpenFromJoystick(), the original code did not (re)enumerate the axes. This returned a new haptic device with 0 axes. Later, when a new effect is created, SDL_SYS_SetDirection() would set the flags to include DIEFF_SPHERICAL, regardless of what the caller actually set. (see Line 566 in SDL_dinputhaptic.c). This would cause the SDL_HapticNewEffect() to fail (or interpret the coordinates incorreclty.)

The patch moves the call to IDirectInputDevice8_EnumObjects() outside of the if() block so that the axes are (re)enumerated for the new haptic device.

Note: For steering wheels it is common for the joystick to have multiple axes (ie steering, throttle, brake), but the haptic portion of the joystick usually only applies to steering.
2016-10-04 03:50:28 -07:00
Sam Lantinga fa0f417631 Fixed build warnings and errors 2016-10-01 14:48:18 -07:00
Ryan C. Gordon 9b4db2b8aa Patched to compile on various platforms. 2016-04-12 18:11:36 -04:00
Ryan C. Gordon c61675dc5d threads: Move SDL's own thread creation to a new internal API.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.

I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
2016-04-12 16:45:10 -04:00
Ryan C. Gordon fa8c83c1c1 Remove almost all instances of "volatile" keyword.
As Tiffany pointed out in Bugzilla, volatile is not useful for thread safety:

https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/

Some of these volatiles didn't need to be, some were otherwise protected by
spinlocks or mutexes, and some got moved over to SDL_atomic_t data, etc.

Fixes Bugzilla #3220.
2016-01-03 06:50:50 -05:00
Sam Lantinga 42065e785d Updated copyright to 2016 2016-01-02 10:10:34 -08:00
Philipp Wiesemann 0e45984fa0 Fixed crash if initialization of EGL failed but was tried again later.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
2015-06-21 17:33:46 +02:00