Add the ability to get more detailed information about controllers

[sanjay900]

It would be good to have more detailed information about the different supported controllers.

GIP

It would be good to have access to the GIP metadata, especially since that can give us the ability to look at the PreferredTypes and SupportedInterfaces, which would be very useful for things like instruments, which tend to use a common PreferredType or SupportedInterface to dictate that they speak the same protocol

Xinput

It would be good to have access to XInput capabilities in their raw form. This would let us do things like figure out if a controller is an instrument, and there were several xinput controllers that did crazy things like putting vendor information into their capability data, so having access to that would be very useful for identifying all these controllers correctly.

HID

It would be good to have access to the hid descriptor or at least a list of all supported usages, as that can then let you do things like identify various controllers based on if they support various vendor feature reports, and that gives us more ways to identify controllers.

[sanjay900]

Curious what your input is on this one, @lsalvadormsft

[sanjay900]

Would probably be something best tackled alongside #25

[lsalvadormsft]

@sanjay900 hear you on the request. Since this would imply header changes, it would have to go in a major GameInput revision. That said, we offer the interface path in the API so that you can cross-reference devices with other APIs. Would that fit your use case? For HID devices, you could use this and the HidD APIs to get access to the descriptor information.

For GIP and XInput, what type of information were you hoping to get exactly? Based on that, we might be able to extract the required information from the device itself.

[sanjay900]

@sanjay900 hear you on the request. Since this would imply header changes, it would have to go in a major GameInput revision. That said, we offer the interface path in the API so that you can cross-reference devices with other APIs. Would that fit your use case? For HID devices, you could use this and the HidD APIs to get access to the descriptor information.

For GIP and XInput, what type of information were you hoping to get exactly? Based on that, we might be able to extract the required information from the device itself.

For HID, that probably could work, and that could be something that gets implemented later with the next major revision perhaps.

For XInput, id pretty much just want the entire capabilities payload, since we need things like the sub type but a lot of the instruments shoved data into the gamepad capabilities as well, they put VID and PID information into the stick capabilities as there was no easy way to obtain VID and PID information on console.

For GIP, youd want the ability to get things like the SupportedInterfaces and PreferredType, since that would then give people a way to match raw devices by type instead of having to hardcode in vids and pids. Right now, games like Fortnite have to hardcode in a list of supported guitar and drum peripherals by vid and pid, but if we had the PreferredType from the GIP metadata payload, they could instead be looking for devices by that, which was how RB4 worked on the xbox one.
Theres a few new instruments being made at the moment and it would be nice if they didn't have to hardcode each and every one into Fortnite (and other new games being made at the moment!).

For example, the RB guitars used the following preferred type strings

• PDP.Xbox.Guitar.Jaguar
• MadCatz.Xbox.Guitar.Stratocaster

and the following guids:

• 0D2AE438-7F7D-4933-8693-30FC55018E77
• 1A266AF6-3A46-45E3-B9B6-0F2C0B2C1EBE

[sanjay900]

Though i think a more is better approach is probably best, so for GIP the entire metadata payload would be great, so something like this one (from a PDP xb1 guitar)

{
  "MetadataHeader": {
    "MajorVersion": 1,
    "MinorVersion": 0
  },
  "DeviceMetadata": {
    "SupportedDeviceFirmwareVersions": [
      { "Major": 1, "Minor": 0 }
    ],
    "SupportedAudioFormats": [],
    "SupportedInSystemCommands": [1, 2, 3, 4, 6, 7],
    "SupportedOutSystemCommands": [1, 4, 5, 6, 10],
    "PreferredTypes": [
      "PDP.Xbox.Guitar.Jaguar",
      "Windows.Xbox.Input.NavigationController"
    ],
    "SupportedInterfaces": [
      "1a266af6-3a46-45e3-b9b6-0f2c0b2c1ebe",
      "b8f31fe7-7386-40e9-a9f8-2f21263acfb7", // Windows.Xbox.Input.INavigationController
      "9776ff56-9bfd-4581-ad45-b645bba526d6"  // Windows.Xbox.Input.IController
    ]
  },
  "Messages": [
    {
      "MessageType": 32,
      "MessageLength": 14,
      "DataType": "Custom",
      "IsSequenced": true,
      "IsDownstream": true,
      "Period": 0,
      "PersistenceTimeout": 0
    },
    {
      "MessageType": 33,
      "MessageLength": 5,
      "DataType": "Custom",
      "IsSequenced": true,
      "IsUpstream": true,
      "Period": 0,
      "PersistenceTimeout": 0
    }
  ]
}

[sanjay900]

And for xinput the entire payload for the capabilities would be useful, so this data (from an xinput gamepad)
You can see here what i mean by putting the VID and PID and Revision in the gamepad input capability data as well.

{
  "type": 1, // Gamepad
  "subType": 8, // Drumkit
  "flags": 13, // 0x000D: Force feedback, voice, plug-in modules
  "gamepad": {
    "buttons": 62463,   // 0xF3FF
    "leftTrigger": 0,   // 0x00
    "rightTrigger": 0,  // 0x00
    "leftStickX": 5604, // 0x15E4
    "leftStickY": 304,  // 0x0130
    "rightStickX": 256, // 0x0100
    "rightStickY": -64  // 0xFFC0
  },
  "vibration": {
    "leftMotor": 0,
    "rightMotor": 0
  }
}

[sanjay900]

One of my main drivers is unity here, where they at some point pivoted to reading all their xinput inputs via gameinput instead of xinput to simplify things, but that broke the ability to use instruments so we had to manually add that support back ourselves. If it was possible to expose that information via gameinput then it would hopefully be possible to get these devices properly supported with unity natively again

But tbh it would just be nice to have a single API that gave you everything you needed without needing to reach out to other APIs.