Terminology of inputs.

[Grovkillen]

Currently it's suggested that the inputs are either "button" or "axis". I find this too wide.

I suggest the following:

button: "input's with state either 0 or 1, default 0"
toggle: "input's with state either 0 or 1, no default" <--- not part of "standard gamepad"
trigger: "input's with state range from 0 to 1, default 0"
spring: "input's with state range from 1 to 0, default 1" <--- not part of "standard gamepad"
dpad: "input's with 9 states; 1(up), 2(down), 3(left), 4(right), 5(upleft), 6(downright), 7(downleft), 8(upright). default 0"
handle: "input's with one axis with state range from -1 to 1, default NaN" <--- not part of "standard gamepad"
joystick: "input's with two axis with state(s) range from -1 to 1, default NaN"
tweezer: "input's with three axis with state(s) range from -1 to 1, default NaN" <--- not part of "standard gamepad"

left cluster: "input's that are reachable for the left hand"
right cluster: "input's that are reachable for the right hand"
menu cluster: "input's that are reachable with left and/or right hand with only a small movement"

*default means the state that the gamepad will output if the input isn't touched (some spring back, other's don't)
*spring I like to think of this as a spring which is engaged like in a hand grenade and when you release the safety lever it goes from safe 1 to less safe to unsafe 0.
*handle, think of remote controlled cars
*tweezer, made most sense to me.... and scalpel sounded too bloody.

[Grovkillen]

Addon to this. I suggest the term "gamepad" to describe a human interface device that uses one or multiple of the above described inputs. Gamepad's by definition only interact with the human in such a way that the human uses their hands or feet to manipulate the input's output value.

Other HID devices will thus be described under a different term.

A gamepad with the following inputs (not taking into account on their placements on the actual hardware) would be of type "standard gamepad":

• 11 buttons
• 2 triggers
• 1 dpad
• 2 joysticks

If a "standard gamepad" have the input's located in these clusters the gamepad have a mapping of "standard":

left: 2 buttons (joystick press, shoulder), joystick, dpad, trigger
right: 6 buttons (joystick press, shoulder + 4 in a NSEW pattern), joystick, trigger
menu: 3 buttons

[nondebug]

These input types are primarily useful for describing input devices that don't follow the standard gamepad. If we add a new input type to the spec I think it should be because we're adding a new standard device type that requires it. Can you describe how these would be used as part of a new standard device type?

Addon to this. I suggest the term "gamepad" to describe a human interface device that uses one or multiple of the above described inputs. Gamepad's by definition only interact with the human in such a way that the human uses their hands or feet to manipulate the input's output value.

For the purposes of the spec, a gamepad is anything that provides gamepad data. It might be a virtual device operated by software rather than a physical input device operated by a human.

Note that for actual HID-class devices you can use WebHID, which is likely a better fit for nonstandard HID input devices than Gamepad API:

https://wicg.github.io/webhid/

[Grovkillen]

For the growing interest of playing retro games you find USB controllers that look like NES, SNES N64 and GC controllers. The first two only got dpad and no joystick for example. Flight simulators are hugely popular and you have controllers which have multiple variants of the suggested inputs. Another type of gamepad is the ones used by car games with a steering wheel (which is by my terminology a "handle" type input).

[nondebug]

I think NES, SNES, and GC are adequately covered by "Standard Gamepad". For a gamepad to use the Standard mapping it doesn't need to have every button or axis defined by the spec, it's fine if some buttons or axes are missing. NES and SNES style gamepads should have no axes, only buttons.

N64 doesn't match the Standard Gamepad layout but I think it's still better to consider it a Gamepad rather than something new (Standard N64?). If we treat it as something other than a Gamepad then it won't function correctly in apps that expect a Standard Gamepad. Instead I think we should do our best to shoehorn it into Standard Gamepad. Currently Chrome doesn't support any N64 adapters but if it did I'd probably map it like this:

buttons[0] = A button
buttons[1] = C-down
buttons[2] = B button
buttons[3] = C-left
buttons[4] = L button (left shoulder)
buttons[5] = R button (right shoulder)
buttons[6] = Z trigger
buttons[7] = unmapped (would be right trigger)
buttons[8] = unmapped (would be Back/Select)
buttons[9] = Start
buttons[10] = unmapped (would be left stick click)
buttons[11] = unmapped (would be right stick click)
buttons[12] = D-pad up
buttons[13] = D-pad down
buttons[14] = D-pad left
buttons[15] = D-pad right
buttons[16] = unmapped (would be Meta)
buttons[17] = C-right (extra button 1)
buttons[18] = C-up (extra button 2)

axes[0] = analog stick X
axes[1] = analog stick Y
axes[2] = unmapped
axes[3] = unmapped

I think a new "Standard Wheel" addition to the spec makes a lot of sense, possibly we would add "handle" and "spring" inputs to the spec to represent the wheel and pedals. However, these would still be represented by values in the axes and buttons array, we'd just give special meaning to the values in particular indices like we do for Standard Gamepad.

A "Standard Flight Stick" would probably make sense as well, but I don't know as much about the variety of inputs on flight sticks. It would be helpful to do a survey on modern flight sticks to see which inputs are common enough to be included in the standard.

[Grovkillen]

Sounds like a plan! 😉

[mrmcpowned]

I like the idea of the Wheel and Flight Stick definitions rather than the breakdown as well.

Something to keep in mind is that currently wheels and flight sticks will appear as multiple controllers due to their control units being interpreted separately. That might be because the HID interface interpreted it as such, but it makes me wonder if user agents should apply some transformations to consider them a singular gamepad...

[nondebug]

Something to keep in mind is that currently wheels and flight sticks will appear as multiple controllers due to their control units being interpreted separately. That might be because the HID interface interpreted it as such

I think this is fine as long as the HID interfaces are all part of the same USB device. We can walk the device tree to discover other interfaces exposed by the same physical device.

It's not clear to me whether there are wheel or flight stick controllers where the control units are separate USB or Bluetooth devices. In that case it gets a lot more complex since the browser needs to make decisions about which devices should be associated. Typically there's no UI for gamepad configuration so the browser needs to make those associations without the user's help. If the browser gets it wrong, the user will probably need to manually disconnect and reconnect devices in the correct order to fix it.

but it makes me wonder if user agents should apply some transformations to consider them a singular gamepad...

I added some transformation logic in Chrome for Switch Joy-Cons. If you connect a matching pair of Joy-Cons, they're automatically combined into a singular "Joy-Con L+R" gamepad. This makes some use cases easier (playing a game with both Joy-Cons held by one player) and others impossible (there's no way to keep the L and R as separate gamepads). I think it works okay for Joy-Cons but I'm not convinced it would work well for other devices.

Transformation is problematic for applications that attempt to identify specific gamepad models. For instance, Dualshock4 has extra buttons beyond those defined in the Standard Gamepad. To access these safely, the application should first verify that the device is a Dualshock4. Usually this is done by checking the Gamepad.id string against known values.

Suppose we want to combine a particular USB wheelbase with a particular USB pedal accessory. Each of these devices might have extra inputs beyond those defined in the Standard Wheel. In order for applications to access those inputs, there needs to be a way for the application to detect which devices make up the transformed gamepad. Should Gamepad.id include hardware information for both the wheelbase and pedal accessory? That doesn't seem right to me. It might be better to keep them as separate Gamepads and allow the application to associate them. If this use case turns out to be common, maybe we should allow for separate "Standard Pedals" and "Standard Wheelbase".