nondebug
commented
1 year ago WebHID isn't sufficient to implement Gamepad API because not all gamepads are HID. The main offender is Xbox controllers connected by USB. Newer Xbox controllers are HID when connected by Bluetooth but they use a proprietary protocol when connected by USB. If the USB interface isn't claimed then we could use WebUSB to implement Gamepad API for these devices. However, the USB interface is typically claimed by a platform-level driver that exposes the gamepad inputs through a dedicated high level input API. The driver has exclusive access to the USB interface so applications are forced to consume inputs through the high level API.
A higher level Gamepad API enables the browser to be a more effective user agent. Consider that modern gamepads may have gyroscopes, accelerometers, and microphones that should not be exposed to script without the user's permission. If you grant permission to the device via WebHID then you're granting permission to access any features supported through the device's HID interface. Gamepad API better protects users' privacy by exposing a limited set of capabilities.
Even if a JS library based on low level device APIs could provide the same level of support for all gamepads that we currently have in Gamepad API, I think it's generally better to consume gamepad inputs via the platform's high level input APIs. A platform that supports virtual gamepads may inject the virtual device directly into the high level input API rather than creating a virtual HID. Similarly, a platform may provide additional features like button remapping or calibration. If the browser only enumerates gamepads through low level APIs then it may not see virtual devices, and if the browser only consumes low level inputs then it may not be able to take advantage of platform features that modify inputs.
7ombie
If I understand correctly, developers can use the WebHID API to implement gamepad support. The API would be lower-level than the Gamepad API, but also considerably more powerful, supporting workers, and permitting features (player LEDs, rumble etc) that are unavailable via the Gamepad API. Is that correct?
If the Gamepad API only provides a subset of what WebHID provides, just at a higher level, then the Gamepad API Proposal is at odds with the entire extensible Web Manifesto. According to the Manifesto, WebHID should be the focus, and higher-level gamepad APIs should be developed as JS libraries in userland, with browsers maybe adding features to optimize established best practices, once they've had time to evolve naturally.
Pragmatically speaking, forms of the Gamepad API have already shipped, and there may be longterm utility in a simple, high-level gamepad API (even if it's only available on the main thread) to lower the bar for students learning to code by making games etc.
I'm not certain what the implications are, but wanted to ask if I at least have the premise correct. Does the Gamepad API do anything that WebHID cannot?