Skip to content

Explore host-side physical gamepad input for OBS overlays #10

Description

@SYMBaiEX

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

  • 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.

Activity

  1. added
    cycle-2Tracked work for the OpenController AI and Gaming Improvement Cycle 2
    cycle-2-candidateEvidence-backed implementation candidate pending Cycle 2 selection
    on Oct 4, 2026
  2. added
    cycle-2-deferredConsidered but deferred from the active Cycle 2 build scope
    and removed
    cycle-2-candidateEvidence-backed implementation candidate pending Cycle 2 selection
    cycle-2Tracked work for the OpenController AI and Gaming Improvement Cycle 2
    on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cycle-2-deferredConsidered but deferred from the active Cycle 2 build scope

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions