Re: [w3c/gamepad] Interop 2025 investigation effort - Gamepad API testing (Issue #219)

nondebug left a comment (w3c/gamepad#219)

Gamepad spec maintainers met on March 13 and discussed the investigation effort, notes are [here](https://docs.google.com/document/d/1oBV4K6rCZOn0p9XlMXBkLZBB-wcEPTUDtiCOwf_FusA/edit?tab=t.0).

@sadym-chromium this looks like a good starting point, I think the overall shape is what we want (methods to connect/disconnect simulated gamepads, input actions to update input state).

There are two transformations performed on gamepad inputs before returning them to script, if possible I'd like to make both of these behaviors testable:

* Reordering buttons and axes
* Normalizing button and axis input values

The reordering step is trivial (and doesn't need to be tested) when reading inputs from a high-level API like XInput that already assigns a specific meaning to each button and axis. However, for generic HID gamepads the remapping step can be somewhat complex and it would be valuable to have tests to verify that the same HID gamepad is mapped consistently in different browsers. To make this testable, we need a way to provide the information that would normally be deduced from the report descriptor. We also need a way to provide the updated input values in the same logical form that the gamepad would provide them.

To test the normalization step we need the logical input value, its minimum and maximum bounds, and whether the input should be mapped as a button or an axis.

Simulating a HID gamepad would satisfy both of these, but not all platforms support HID. The test API should be allowed to omit support for simulated HID gamepads if the underlying operating system doesn't support HID. I think it would be useful to have a second simulated gamepad type to represent a non-HID gamepad. This simulated gamepad would skip the reordering step and instead require the user to define buttons and axes (with logical bounds) in the same order they should be returned in Gamepad API. The normalization step would be performed as usual.

I think it would also be useful to have a third type of simulated gamepad that skips both reordering and normalization. I expect there will be use cases where inputs are recorded through Gamepad API and then played back through a simulated gamepad. To avoid the need to convert from normalized inputs back into logical inputs we should allow tests to provide inputs in the same form they are returned in Gamepad API.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/219#issuecomment-2770914552
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/219/2770914552@github.com>