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

DirectInput: Incorrect joystick mapping when attaching new joysticks #2134

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

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Windows (All), x86_64

Comments on the original bug report:

On 2016-03-28 21:20:00 +0000, Jimb Esser wrote:

Created attachment 2398
proposed fix

Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput.

I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).

The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.

I have attached a patch for this, and would be willing to work on getting it into an acceptable state, but it should be usable by anyone else who needs to work around this issue to get dynamically adding/removing of controllers on Windows to work.

Patch also includes a trivial change to fix my Xbox 360 controllers not being recognized by the gamecontroller API (They show up as "XBOX 360" all caps, which was not in the strings currently searched for ).

On 2017-08-12 03:52:06 +0000, Sam Lantinga wrote:

I ran into something like this separately when testing something a few months ago. Can you check the latest snapshot and see if this is fixed for you?
http://www.libsdl.org/tmp/SDL-2.0.zip

If that doesn't fix it, as I suspect it may not, please feel free to get your patch in a usable state based on the latest Mercurial and I'd love to add it.

Thanks!

On 2017-08-14 03:43:01 +0000, Sam Lantinga wrote:

Patch cleaned up and applied, thanks!
https://hg.libsdl.org/SDL/rev/10bfd8a3ecd8

On 2017-08-14 19:43:56 +0000, Jimb Esser wrote:

Looks great, thanks for merging it!

On 2017-08-14 20:08:56 +0000, Sam Lantinga wrote:

You're welcome! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant