SDL Archaeology: Where does XINPUT_GAMEPAD_EX come from?

Hey all, I’m a Wine dev looking into our implementation of xinput.

We have a struct called XINPUT_GAMEPAD_EX. As far as I can tell, this struct does not actually exist in the Windows PSDK, nor almost anywhere on the Internet. It is referenced only in SDL’s header files, in some mumble-voip bugs which explicitly copy it from SDL, and in Wine itself, where I believe it was also copied from SDL.

I believe this struct originated in this changeset from SDL:

changeset:   6690:9548c8a58103
user:        Sam Lantinga <slouken@libsdl.org>
date:        Mon Nov 26 16:37:54 2012 -0800
summary:     Added hotplug joystick support and simplified game controller API, courtesy of Alfred Reynolds

The struct is used with an undocumented function in xinput, ordinal value 100, which SDL names XInputGetState_t. Since this is undocumented, it makes some sense that its struct is undocumented as well. However, I believe that XInputGetState_t uses the same struct as XInputGetState, and the XINPUT_GAMEPAD_EX struct can be eliminated from SDL to prevent confusion going forward.

Aside from the question of whether this struct even exists, its dwPaddingReserved member caused a real problem for Wine. Since we implement xinput, we would write to this member. However, real Windows titles that call XInputGetState_t give us a buffer that is missing the dwPaddingReserved member, so we end up with a buffer overrun and difficult-to-diagnose crashes. And indeed, if you give a struct with a dwPaddingReserved member to MS’s xinput, their implementation does not overwrite this member. So the evidence is that it never existed, and XInputGetState_t takes the same struct as XInputGetState.

I plan to fix this by eliminating the struct in Wine’s headers. But I thought I’d let you know about this issue, and also take the opportunity to ask if anyone knows where this struct, and the dwPaddingReserved member in particular, came from.

Any thoughts?

Hello,

I ran into something similar recently…

This is likely related to the undocumented routine (“XInputGetStateEx” as
it’s referred by some references I’ve seen online) which returns a
slightly different struct (“XINPUT_STATE_EX”) than the normal call, which
includes access to the state of the GUIDE button (not normally accessible
via the XInputGetState and the regular XINPUT_STATE struct).

I’m not sure why M$ doesn’t just document this and support it, but the
Steam Client and many other things obviously make use of this (GUIDE
button brings up the Steam Overlay, for example)… so it’s real, and the
XInput DLL and spec hasn’t changed in quite a while, so it’s not like M$
is gonna change things and make it stop working.

Likely, M$ makes use of it (“secretly”) for their own internal code (i.e.
their header has the “secret” routine and struct in it). My guess is,
they just hid it from the public API so games on the XBOX don’t intercept
and/or break the operation of the GUIDE button for quitting out of a game
and returning to the menu system, etc.

Here’s an example of people discussing the details on this…

https://www.google.com/search?client=ubuntu&channel=fs&q=xinput+guide+button&ie=utf-8&oe=utf-8

It was the first hit from a Google search for “xinput guide button”.

Hope this helps,

Ed