Identify which of multiple keyboards an event came from

When multiple keyboards are available, there is currently no way to distinguish which one a KeyboardEvent came from using web APIs. We should have one.

Use case 1: special-purpose keyboards/keypads that are used alongside normal keyboards, for example financial trading keypads and retail POS keyboards. They are used to provide quick access to regular/time-sensitive actions, while the normal full-sized keyboard is used for other input. The key codes they expose (as far as I know) are the same as for the normal keyboard (but the mappings can be programmed), so the listening application needs to use the source of the key event to determine what action to take.

Use case 2 (similar): gaming keyboards, if use of the main keyboard is also needed (otherwise the Keyboard Lock API seems like it would do the job).

Things I found, that don’t help:

1. KeyboardEvent.location - identifies which part of the keyboard the event came from, e.g. the numpad.
2. Keyboard Lock API - allows capturing more keys, but not distinguishing where they came from, only works in full screen mode, assumes a single keyboard.
3. Keyboard Map API - describes the buttons on the keyboard, assumes a single keyboard.
4. Input Device Capabilities - firesTouchEvents lets you identify an on-screen keyboard, but doesn’t help when all keyboards have the same capabilities.
5. WebUSB - prohibits access to devices that expose an HID profile.
6. WebHID - not intended for keyboards or other devices that are already well-supported through high-level input APIs.

Some initial rough thoughts on what solutions (of increasing capability) would provide:

1. Distinguish which keyboard a KeyboardEvent came from.
2. Distinguish whether it came from the “main keyboard” or a secondary one.
3. Inform what layout of keyboard it is (e.g. 48-key keypad).
4. Inform what particular customised keyboard it is (e.g. FooBroker Fixed-Income trading keypad, where the buttons are labelled to do particular things, and some of the keys are blanked out and others are combined using multi-switch keycaps).
5. Ability to discover the custom keyboard before any key presses are made on it
6. Perhaps the user should need to grant permissions for the above. Allow the application to request distinguishability/information of/about a custom keyboard matching given filter criteria (like in WebUSB) - if a device satisfying the criteria was available, the user would be prompted to grant access.
7. Some further capability as seen in WebUSB where the device could have embedded information about which website it should be used with, allowing a notification to be popped up when it’s plugged in.

I’m not sure what this API would look like, especially given that the existing keyboard API assumes a single keyboard.

Cross posted to https://github.com/w3c/uievents/issues/226

The more capable solution ideas above would probably be beyond the scope of UI Events.

At least some of these kinds of keyboards (e.g. X-keys) have multiple modes - including one that exposes the device on the USB HID Consumer Page. That page isn’t a protected usage under WebHID (unlike GenericDesktop>Keyboard/Keypad, so the device could be accessed via WebHID and there is no need for what I’m asking for here.