You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Explore host-side physical gamepad input for OBS overlays #10
A creator on macOS wants a transparent controller-input overlay in OBS while recording PS Remote Play. The overlay renders, but OBS/CEF does not expose their Bluetooth DualSense to the browser source. Chrome detects the controller, so the creator asks whether the overlay can read input outside OBS and forward it to the overlay.
Direct evidence
DualSense Studio issue #2, opened 2026-09-29. The report gives macOS 26.5.2, OBS 32.2.2, Chrome 153, and a Bluetooth DualSense. Chrome's Gamepad Tester detects the controller; the same tester in OBS's browser source reports all slots as none detected. Restarting OBS, recreating the source, and using Interact did not help. The author explicitly proposes an external input bridge and notes they have not confirmed whether PS Remote Play or Bluetooth contributes.
This is one firsthand report, not evidence of prevalence. The diagnosis points to OBS/CEF but is not confirmed.
Workaround and limits
The report does not identify a working OBS Browser Source workaround. The author prefers keeping a transparent Browser Source over window capture plus chroma key. Chrome sees the device, but that alone does not feed controller state to OBS.
OpenController fit
OpenController can render and serve overlay state, and createOverlayServer accepts a Controller or caller-published state. It does not capture a physical controller: the native backends create virtual devices from OpenController-generated state, which is the opposite direction. A host-side input source could read a physical controller and publish normalized state to the existing overlay server, avoiding the OBS browser's gamepad API dependency.
Proposed outcome
After Cycle 2 discovery selects this opportunity, prototype an opt-in macOS physical-gamepad input source that publishes normalized state into createOverlayServer. Keep it independent of the virtual-device output path. Begin with the reported macOS/OBS/CEF use case; only expand platforms after separate evidence and a reviewed backend design. If macOS permissions or APIs make reliable capture unsuitable, document the result and close as deferred rather than implying the CEF issue is fixed.
Acceptance checks
Define and document one supported macOS input backend, controller-selection behavior, supported controls, and required permissions before implementation.
In a testable macOS setup, read button, axis, and trigger changes from a connected physical controller without relying on navigator.getGamepads() inside OBS/CEF.
Publish those changes through the existing overlay server and verify a transparent OBS Browser Source reflects them while another app is foregrounded.
Handle no device, disconnect, reconnect, and multiple devices with explicit selection; neutralize stale state after disconnect.
Add automated tests for state normalization, device loss, and publication, and document which checks require physical hardware and OBS.
Keep the source opt-in and read-only; do not synthesize input back to the physical controller or create a virtual gamepad as a side effect.
Non-goals and risks
Does not fix OBS/CEF's Gamepad API or guarantee that every OBS/macOS/controller combination works.
Does not promise cross-platform physical input capture, controller remapping, rumble, motion, or arbitrary HID support in this slice.
Physical-device APIs can require permissions, vary by OS/controller, and conflict with exclusive access or privacy expectations. Do not request broad device access silently; make selection and permission behavior explicit.
The source report is a single unconfirmed case; verify the reported setup and assess whether a supported macOS API can read input safely before committing to implementation.
Status and follow-up
Deferred from Cycle 2. Do not implement this slice in the current cycle. Revisit only after new firsthand reports support the need and a macOS API/permission feasibility review succeeds. If selected later, create a fresh research/build issue and assign it to the appropriate cycle. The evidence and decision are recorded in research issue #7 and roadmap PR #11.
Persona and situation
A creator on macOS wants a transparent controller-input overlay in OBS while recording PS Remote Play. The overlay renders, but OBS/CEF does not expose their Bluetooth DualSense to the browser source. Chrome detects the controller, so the creator asks whether the overlay can read input outside OBS and forward it to the overlay.
Direct evidence
This is one firsthand report, not evidence of prevalence. The diagnosis points to OBS/CEF but is not confirmed.
Workaround and limits
The report does not identify a working OBS Browser Source workaround. The author prefers keeping a transparent Browser Source over window capture plus chroma key. Chrome sees the device, but that alone does not feed controller state to OBS.
OpenController fit
OpenController can render and serve overlay state, and
createOverlayServeraccepts aControlleror caller-published state. It does not capture a physical controller: the native backends create virtual devices from OpenController-generated state, which is the opposite direction. A host-side input source could read a physical controller and publish normalized state to the existing overlay server, avoiding the OBS browser's gamepad API dependency.Proposed outcome
After Cycle 2 discovery selects this opportunity, prototype an opt-in macOS physical-gamepad input source that publishes normalized state into
createOverlayServer. Keep it independent of the virtual-device output path. Begin with the reported macOS/OBS/CEF use case; only expand platforms after separate evidence and a reviewed backend design. If macOS permissions or APIs make reliable capture unsuitable, document the result and close as deferred rather than implying the CEF issue is fixed.Acceptance checks
navigator.getGamepads()inside OBS/CEF.Non-goals and risks
Status and follow-up
Deferred from Cycle 2. Do not implement this slice in the current cycle. Revisit only after new firsthand reports support the need and a macOS API/permission feasibility review succeeds. If selected later, create a fresh research/build issue and assign it to the appropriate cycle. The evidence and decision are recorded in research issue #7 and roadmap PR #11.