Most gamepads roughly follow the layout described in the Standard Gamepad with dual thumbsticks, an 8-direction D-pad, shoulder buttons, triggers, 4+ action buttons grouped on the left, and 3+ buttons grouped in the center. Examples: Xbox 360, Xbox One, Dualshock 3, Dualshock 4, Switch Pro Controller.
Devices that roughly match the Standard Gamepad layout but are missing some of the controls should be mapped as closely as possible to the Standard Gamepad. This makes it difficult to detect the capabilities of devices that diverge from the Standard Gamepad layout. For instance, Apple Remote is enumerated as a gamepad on macOS but does not follow the Standard Gamepad layout and lacks many of the controls that would be expected on a Standard Gamepad.
GCMicroGamepad has a D-pad member (dpad) and three button members (buttonA, buttonX, buttonMenu). The device can be held vertically like a TV remote or horizontally like a gamepad, and may alter the D-pad mapping based on the current orientation.
Using Apple Remote and other devices that provide a subset of Standard Gamepad inputs is difficult because the Gamepad API does not provide a way to discover device capabilities. If an Apple Remote is assigned the Standard Gamepad mapping, applications may assume it supports all Standard Gamepad inputs. This may break applications that require specific controls like thumbsticks or triggers.
To aid applications in detecting this class of device, perhaps we can add a "Standard Micro Gamepad" layout that describes a device like Apple Remote. This may also enable better support for similar devices like all-digital retro game controllers (NES, SNES, etc) and Wiimotes.
Most gamepads roughly follow the layout described in the Standard Gamepad with dual thumbsticks, an 8-direction D-pad, shoulder buttons, triggers, 4+ action buttons grouped on the left, and 3+ buttons grouped in the center. Examples: Xbox 360, Xbox One, Dualshock 3, Dualshock 4, Switch Pro Controller.
Devices that roughly match the Standard Gamepad layout but are missing some of the controls should be mapped as closely as possible to the Standard Gamepad. This makes it difficult to detect the capabilities of devices that diverge from the Standard Gamepad layout. For instance, Apple Remote is enumerated as a gamepad on macOS but does not follow the Standard Gamepad layout and lacks many of the controls that would be expected on a Standard Gamepad.
https://en.wikipedia.org/wiki/Apple_Remote
Apple Remote implements the "micro gamepad" profile supported by the Game Controller framework on macOS:
https://developer.apple.com/documentation/gamecontroller/gcmicrogamepad
GCMicroGamepad has a D-pad member (dpad) and three button members (buttonA, buttonX, buttonMenu). The device can be held vertically like a TV remote or horizontally like a gamepad, and may alter the D-pad mapping based on the current orientation.
Using Apple Remote and other devices that provide a subset of Standard Gamepad inputs is difficult because the Gamepad API does not provide a way to discover device capabilities. If an Apple Remote is assigned the Standard Gamepad mapping, applications may assume it supports all Standard Gamepad inputs. This may break applications that require specific controls like thumbsticks or triggers.
To aid applications in detecting this class of device, perhaps we can add a "Standard Micro Gamepad" layout that describes a device like Apple Remote. This may also enable better support for similar devices like all-digital retro game controllers (NES, SNES, etc) and Wiimotes.
cc @beidson