Describe the solution you'd like
This is a follow-up to issue #3525, which was closed as not planned because Electron's global hotkey listener (globalShortcut) only supports keyboard input and can't be extended to controllers. I think i found a workaround for that which would work nicely for Firebot.
This proposal uses a different mechanism that avoids that limitation entirely: instead of registering controller buttons as OS-level global hotkeys, Firebot renderer polls connected controllers directly via the standard browser Gamepad API (navigator.getGamepads()). This API works with any HID game controller Xbox, PlayStation, generic USB pads, arcade buttons, or simple microcontrollers that present themselves as a gamepad with no per-device drivers or mappings needed. That would make the use of DIY Streampads also possible and less cumbersome because no additional apps like for example for a streamdeck are needed.
Proposed behavior:
- A new "Game Controller Bindings" page (alongside Hotkeys, under the Triggers section of the sidebar) with an item table for adding, editing, enabling/disabling, reordering, and deleting bindings — matching the look and feel of the existing Hotkeys page.
- An "Add/Edit Game Controller Binding" modal where users give the binding a name, press "Record Button" and then press the desired button on their controller to capture it, and configure an effect list to run when that button is pressed.
- No controller-specific button name mapping is required — buttons are referred to generically by their numeric index (e.g. "Button 0", "Button 1", ...) as reported by the Gamepad API's standard buttons array. This keeps the feature controller-agnostic without needing to maintain per-layout name tables for every controller on the market.
- Bindings can optionally be scoped to a specific controller (by its gamepad index) or apply to any connected controller.
- Bindings are persisted per-profile via a new backend manager, the same way hotkeys are.
- When a bound button is pressed, its effect list runs through the existing effect runner.
Additional context
Known limitation/discussion point: detection happens via the Gamepad API in the renderer process, so (unlike OS-level keyboard hotkeys) it requires the Firebot app itself to be running with the Gamepad API actively polling it is not a true system-wide hotkey. But in practice this is fine for Firebot's normal use case (the app is always running while streaming), but I want to flag this difference up front so the team can weigh in on whether that's an acceptable tradeoff.
I have a working POC implementation of this ready following the existing Hotkeys implementation pattern and would like to open a PR against v5 branch once this is approved.
Describe the solution you'd like
This is a follow-up to issue #3525, which was closed as not planned because Electron's global hotkey listener (globalShortcut) only supports keyboard input and can't be extended to controllers. I think i found a workaround for that which would work nicely for Firebot.
This proposal uses a different mechanism that avoids that limitation entirely: instead of registering controller buttons as OS-level global hotkeys, Firebot renderer polls connected controllers directly via the standard browser Gamepad API (navigator.getGamepads()). This API works with any HID game controller Xbox, PlayStation, generic USB pads, arcade buttons, or simple microcontrollers that present themselves as a gamepad with no per-device drivers or mappings needed. That would make the use of DIY Streampads also possible and less cumbersome because no additional apps like for example for a streamdeck are needed.
Proposed behavior:
Additional context
Known limitation/discussion point: detection happens via the Gamepad API in the renderer process, so (unlike OS-level keyboard hotkeys) it requires the Firebot app itself to be running with the Gamepad API actively polling it is not a true system-wide hotkey. But in practice this is fine for Firebot's normal use case (the app is always running while streaming), but I want to flag this difference up front so the team can weigh in on whether that's an acceptable tradeoff.
I have a working POC implementation of this ready following the existing Hotkeys implementation pattern and would like to open a PR against v5 branch once this is approved.