Re: [w3ctag/design-reviews] Gamepad Light Indicator extension API (#362)

When can `setColor()`'s promise reject? Preliminary research suggests that the most obvious way to implement this underneath the hood would be raw HID messages, is the idea to reject when the device does not ACK? (I have to actually dig out a controller and see how this works, it's been quite a while since I've had to interact with a HID interface)

I've gone through a bunch of platform APIs and there doesn't seem to be feature parity across platforms to control lighting; how are (non-Chrome) implementations expected to implement this? I would like to see a interoperability story here; `Gamepad.lightIndicators` doesn't mention how the order of the list is ideally expected, which has been a pain point for the users of the Gamepad API with button order.

Since underlying interfaces across platforms is already inconsistent, it's probably not reasonable to expect all platforms with the same controller on different implementations to behave the same, but consistency *within* each platform would be extremely helpful to the users.

One other silly (but not so useful) idea that came to mind is the possibility of using the game controller lights as a side channel for inter-origin "communication", not sure what the security/privacy implications from that would be with a 3 byte wide bus (given a single RGB LED, with multiple the bus size obviously will increase, but it's still only 24 bits of entropy to work with for each LED.), but leaving that for the next person to think about.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/362#issuecomment-485251835