SDL v2.0.7 joystick oddities

The SDL_JoystickGetDeviceGUID() routine will return something that looks
like a “real” GUID for an XINPUT joystick on Windows (testing with XBox
360 Wireless controller for Windows and the F710 switched to XInput mode)
instead of the “XInput” GUID. It’s nice to see the vendor/product ID.
This could certainly help with the age-old problem of not being able to
have different configs for different types of XInput devices based on
vendor/product ID.

However, it appears that often there is a “phantom” device that shows up
when I plug in one of my test gamepads, in addition to the real device.

What I see is… I plug in the gamepad’s USB receiver, and there is a
delay of several seconds. Then the normal device shows up via a

GUID: 030000006d0400001fc2000000007801 (F710)
GUID: 030000005e040000a102000000007801 (XB360)

then after a second or two, another DEVICEADDED event occurs and the
“phantom” device shows up:

GUID: 03000000de280000ff11000000007801

It doesn’t happen every time, but it happens a lot. If I unplug/plug the
receiver repeatedly, it will eventually work without the “phantom” device
showing up.

So… where is this coming from? Could this possibly have something to do
with the Steam client adding a virtual joystick when my game connects to
Steam? I haven’t been able to make it happen with the “testhotplug”
program so far, but I haven’t tried making testhotplug into a “Steam game”
to see what happens…



Ed Phillips University of Delaware (302) 831-6082
Systems Programmer IV, Network and Systems Services

I found the following GUID in SDL_gamecontrollerdb.h:


It’s named “Steam Virtual Gamepad” but the mapping is for Linux. But it’s
a pretty good hint that this “phantom” device is a Steam thing. I don’t
have the “Generic Gamepad Configuration Support” turned on in the Steam
client… so I’ve yet to be able to determine WHY Steam is creating this
“phantom” virtual device.

In my test case on Windows the version field of the GUID is 0x0178.
Regardless, I don’t think the game controller code in SDL will using any
mapping for an XInput device other than the one with “xinput” in the GUID
field of the mapping string from gamecontrollerdb.h. Is that the

At least we can get the GUID from the joystick device (with
vendor/product) and differentiate between physical XInput devices so we
can allow players to have specific game configurations tied to the GUID if

If Steam is adding a virtual gamepad device entry for each controller you
plug in, can you only use 2 physical controllers before you reach the
4-controller limit of XInput (the real controller shows up as userid 1
and the virtual device shows up as userid 2)? This could be a problem if
you actually need 4 physical controllers active…


This should be fixed in a Steam beta update soon.


FYI, SDL can’t tell which VID/PID matches up with which XInput slot, so if you have more than one controller attached you might see the wrong ones.


March 12

This should be fixed in a Steam beta update soon.

Is there a Steam forum discussion related to this “phenomenon”? I’d like
to get a sense of whether this “phantom” device will/should actually be
used eventually (maybe in preference to the real devices so Steam can do
it’s own remapping stuff).


FYI, SDL can’t tell which VID/PID matches up with which XInput slot, so if you have more than one
controller attached you might see the wrong ones.

So, what does that boil down to? The “XInput Blahblah #” name has
the correct slot number for the detected SDL_Joystick object, but the GUID
returned by SDL_JoystickGetDeviceGUID() for that same object may be for a
different connected device? If that’s the case then we can’t really
depend on using the GUID to differentiate between different user configs
for two XInput devices connected at the same time, even if they are
different make/model, right?

By user configs, I’m referring to the notion that one player wants to use
the “rightshoulder” button for FIRE on the F710 (XInput mode) vs. the
other player wants to use the “righttrigger” for FIRE on the XBox 360
Wireless. Even if we get the user to press the FIRE button they want to
use on the controller their holding, we can’t remember that for next time
because the GUID might be wrong… unless we use the slot number as the
key (and assume that slot 1 be the same controller next time)?

What about the case for an XInput device and a DINPUT device connected at
the same time? Will the XInput device have the correct GUID (VID/PID)?

Will the GUID be correct if there is only one XInput device connected (no
matter how many DINPUT devices)?



When Steam is doing remapping, the “phantom” device will be the only one visible, the real device will be hidden from the input APIs. The bug was just that the virtual device was showing briefly when a real controller was connected.

Yes, I don’t know of any way to tie mapping preferences to a specific controller using XInput. As far as I can tell there’s just no way to know which XInput user index corresponds to what physical controller, by design. If someone finds out how, please let me know!

If there is a single XInput device connected, the GUID should be correct.