w3c / gamepad

Gamepad
https://w3c.github.io/gamepad/
Other
142 stars 48 forks source link

Request: support for analog keyboards #187

Open rektide opened 1 year ago

rektide commented 1 year ago

This is the nichest of niche interests, but I'd love a way on the web to use something like a Wooting 60HE keyboard, which is a 60% keyboard with fully analog keys.

Utterly obvious use cases:

I'm happy to refile this elsewhere but nothing else seems to have the focus on continuous analog streams. Please let me know if I should redirect this ask. Or maybe this should be asked in parallel to multiple specs?

nondebug commented 1 year ago

Exposing keyboard inputs through Gamepad API would put the user at risk. Currently, Gamepad API doesn't enforce any input focus restrictions. A page can receive gamepad inputs even if it's not focused or backgrounded. We think this is fine because gamepads aren't commonly used to enter private information like passwords, and there are known use cases where background gamepad access is desirable.

Keyboards, on the other hand, are commonly used to enter private information like passwords. The operating system uses an input focus model to give the user control over which applications receive keystroke data. A similar focus model is implemented on the web platform to prevent a page from receiving key events meant for a different page, or to prevent a page from capturing keystrokes entered into a protected field.

If we expose pressure-sensitive keyboard inputs through Gamepad API, it gives script access to keystroke data that it would not be able to receive as input events, undermining the browser's input focus model. I don't see a way around this so I think this is probably a non-starter.

reillyeon commented 1 year ago

Agreed that adding keyboard support to the Gamepad API isn't the right solution. I would recommend moving this feature request to the UI Events specification.

7ombie commented 1 year ago

The Web needs a new keyboard API that permits keyboard input to be handled by workers. It cannot be a DOM API, so would need to be quite different to the current keyboard API, but this is not the place to flesh out how that might work. There was a proposal, but the scope was far too broad (it included pointer events and some MIDI stuff), and it died, and nothing has happened since on that front.

User input is generally problematic on the Web, as many APIs lack support for workers, and the main thread is often busy.

I did argue once that the Gamepad API needs to support threads, as a large percentage of videogames respect frame-perfect inputs, which cannot be handled reliably on the main thread, but frankly, that suggestion wasn't well received.

We really need our APIs to permit any user input to be handled by a worker, but that is not going to happen for the Web in any foreseeable future. It's a shame, as it really undermines the Web as a platform.