Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using multiple XInput devices with haptics seems problematic #1097

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Using multiple XInput devices with haptics seems problematic #1097

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
abandoned Bug has been abandoned for various reasons

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

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

Comments on the original bug report:

On 2013-10-01 09:01:39 +0000, Mitchell Keith Bloch wrote:

I've been trying to get two XBox 360 controllers to play nicely together (with haptic feedback), and I'm having a fair bit of trouble.

I've partially(?) resolved some issues:

  1. Inability to use haptics with more than one Xinput device.
  2. Errors on close/quit.
  3. Use of SDL_HAPTIC_INFINITY was causing very quick termination of vibration.

diff -r cf8dd3177612 src/haptic/windows/SDL_syshaptic.c
--- a/src/haptic/windows/SDL_syshaptic.c Mon Sep 30 21:57:03 2013 -0700
+++ b/src/haptic/windows/SDL_syshaptic.c Tue Oct 01 04:54:38 2013 -0400
@@ -636,8 +636,8 @@
int
SDL_SYS_JoystickSameHaptic(SDL_Haptic * haptic, SDL_Joystick * joystick)
{

  • if ((joystick->hwdata->bXInputHaptic == haptic->hwdata->bXInputHaptic) && (haptic->hwdata->userid == joystick->hwdata->userid)) {
  •    return 1;
    
  • if ((joystick->hwdata->bXInputHaptic == haptic->hwdata->bXInputHaptic)) {

  •    return haptic->hwdata->userid == joystick->hwdata->userid;
    

    } else {
    HRESULT ret;
    DIDEVICEINSTANCE hap_instance, joy_instance;
    @@ -1185,6 +1185,7 @@
    return &GUID_Friction;

    case SDL_HAPTIC_CUSTOM:

  • case SDL_HAPTIC_LEFTRIGHT:
    return &GUID_CustomForce;

    default:
    @@ -1322,7 +1323,10 @@
    XINPUT_VIBRATION vib = &effect->hweffect->vibration;
    SDL_assert(effect->effect.type == SDL_HAPTIC_LEFTRIGHT); /
    should catch this at higher level */
    SDL_LockMutex(haptic->hwdata->mutex);

  •    haptic->hwdata->stopTicks = SDL_GetTicks() + (effect->effect.leftright.length * iterations);
    
  •    if(effect->effect.leftright.length == SDL_HAPTIC_INFINITY || iterations == SDL_HAPTIC_INFINITY)
    
  •      haptic->hwdata->stopTicks = SDL_HAPTIC_INFINITY;
    
  •    else
    
  •      haptic->hwdata->stopTicks = SDL_GetTicks() + (effect->effect.leftright.length * iterations);
       SDL_UnlockMutex(haptic->hwdata->mutex);
       return (XINPUTSETSTATE(haptic->hwdata->userid, vib) == ERROR_SUCCESS) ? 0 : -1;
    
    }

Unfortunately, I'm still having trouble. With 2 devices connected at launch, one seems to be triggering a SDL_CONTROLLERDEVICEREMOVED event immediately, for no apparent reason. If ignored, both devices function normally. However, while disconnecting controller 1 and reconnecting it works fine, attempting to the same with controller 0 results in errors, and I'm unable to reconnect to get any input at all. Is it supposed to be a requirement that controllers be disconnected in descending order? Any thoughts would be appreciated.

On 2013-10-01 18:25:46 +0000, Mitchell Keith Bloch wrote:

Okay, moving on from haptic issues, I've fixed the most critical issue I've found in XInput support:

diff -r cf8dd3177612 src/joystick/windows/SDL_dxjoystick.c
--- a/src/joystick/windows/SDL_dxjoystick.c Mon Sep 30 21:57:03 2013 -0700
+++ b/src/joystick/windows/SDL_dxjoystick.c Tue Oct 01 14:23:15 2013 -0400
@@ -732,11 +732,11 @@

         pNewJoystick->pNext = SYS_Joystick;
         SYS_Joystick = pNewJoystick;
  •        return;   /* already in the list. */
       }
    
       pPrevJoystick = pNewJoystick;
       pNewJoystick = pNewJoystick->pNext;
    
  •    return;   /* already in the list. */
    

    }

    pNewJoystick = (JoyStick_DeviceData *) SDL_malloc(sizeof (JoyStick_DeviceData));

However, I still seem to be missing SDL_CONTROLLERDEVICEREMOVED events in circumstances which I've failed to narrow down. Iterating through my Joystick pointers and destroying the structures associated with them when they're detected as detached seems to work well enough for now, but it's a hack.

On 2013-10-03 07:58:04 +0000, Sam Lantinga wrote:

Ryan, can you take a look at this for the SDL 2.0.1 release?

Thanks!

On 2013-10-20 19:58:01 +0000, Ryan C. Gordon wrote:

Ok, these patches are now split up and in revision control:

https://hg.libsdl.org/SDL/rev/97fa86ce5a2e
https://hg.libsdl.org/SDL/rev/b92b8c52946c
https://hg.libsdl.org/SDL/rev/70f1d63482d0
https://hg.libsdl.org/SDL/rev/038da46576e6

Still looking at the SDL_CONTROLLERDEVICEREMOVED events issue.

--ryan.

On 2013-10-21 04:59:40 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 3)

Still looking at the SDL_CONTROLLERDEVICEREMOVED events issue.

Can't reproduce this with one X360 controller here, and my second controller just burned itself out. So, hopefully this is good enough for now.

If this is still failing for you with the latest in Mercurial, please reopen this bug.

(And thank you for all the patches in any case!)

--ryan.

On 2013-10-23 18:54:43 +0000, Mitchell Keith Bloch wrote:

Your multiple XBox controllers and haptics fixes seem to work. Not everything is fixed yet, however.

You missed "2. Errors on close/quit." Sorry for glomming the errors together. Without my workaround, I get SDL_SetError("Haptic: Unknown effect type."). I assume this is because the LEFTRIGHT thing was a last minute change. This is my workaround:

diff -r 62f562a475e1 src/haptic/windows/SDL_syshaptic.c
--- a/src/haptic/windows/SDL_syshaptic.c Wed Oct 23 00:58:20 2013 -0400
+++ b/src/haptic/windows/SDL_syshaptic.c Wed Oct 23 14:45:42 2013 -0400
@@ -1187,6 +1187,7 @@
return &GUID_Friction;

 case SDL_HAPTIC_CUSTOM:
  • case SDL_HAPTIC_LEFTRIGHT:
    return &GUID_CustomForce;

    default:

Additionally, getting SDL_CONTROLLERDEVICEREMOVED events is still rare. I don't see them the vast majority of the time, and once it provided an incorrect "which" value of 17, for one of three controllers assigned 0, 1, or 2. The CONTROLLERDEVICEADDED events are fine. (I'm not sure how to even generate SDL_CONTROLLERDEVICEREMAPPED for testing purposes.)

On 2013-10-23 20:57:15 +0000, Ryan C. Gordon wrote:

You missed "2. Errors on close/quit." Sorry for glomming the errors
together. Without my workaround, I get SDL_SetError("Haptic: Unknown effect
type."). I assume this is because the LEFTRIGHT thing was a last minute
change. This is my workaround:

Here's mine: https://hg.libsdl.org/SDL/rev/15027aa2cf21

Additionally, getting SDL_CONTROLLERDEVICEREMOVED events is still rare. I
don't see them the vast majority of the time, and once it provided an
incorrect "which" value of 17, for one of three controllers assigned 0, 1,
or 2. The CONTROLLERDEVICEADDED events are fine. (I'm not sure how to even
generate SDL_CONTROLLERDEVICEREMAPPED for testing purposes.)

Not getting REMOVED events is a bug. I can't trigger it here, but I'm down to one working X360 controller, and maybe it needs more than one. That being said:

You will get ADDED events for all controllers, so you can decide to open them if you want. You will not get a REMOVED event for a game controller unless you've opened that specific device before it was unplugged. Confusingly, joystick devices (opened or not) will trigger REMOVED events. This difference might be a bug. Is that what's happening to you here?

The "which" value is the joystick index for ADDED events, and its instance id for REMOVED. So getting a different value between adding and removing is possible and likely (but, yes, this is unnecessarily confusing, too).

You won't get REMAPPED events unless you manually change a controller's mapping; they don't happen due to OS-level events. You'll probably never see one. So this part is okay.

--ryan.

On 2013-10-23 21:08:59 +0000, Ryan C. Gordon wrote:

You will get ADDED events for all controllers, so you can decide to open
them if you want. You will not get a REMOVED event for a game controller
unless you've opened that specific device before it was unplugged.
Confusingly, joystick devices (opened or not) will trigger REMOVED events.

Rereading this, I don't think I was clear: the game controller API only reports SDL_CONTROLLERDEVICEREMOVED for devices you SDL_GameControllerOpen()'d. The lower-level joystick API reports SDL_JOYDEVICEREMOVED for all devices, opened or not.

--ryan.

On 2013-11-11 20:37:30 +0000, Mitchell Keith Bloch wrote:

I'm missing REMOVED events for game controllers which I've SDL_GameControllerOpen()'d, unfortunately. Additionally, I'm missing REMOVED events with only one controller, so I'm unsure as to why you're entirely unable to reproduce the bug.

That the "which" values have different semantics for ADDED and REMOVED events is really confusing. Is it safe to assume that it's too late to change the semantics of the which values for REMOVED events?

On 2018-08-06 21:20:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

@SDLBugzilla SDLBugzilla added abandoned Bug has been abandoned for various reasons bug labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned Bug has been abandoned for various reasons
Projects
None yet
Development

No branches or pull requests

1 participant