[GH-ISSUE #285] Multi-Controller RF Sessions Fail After First Connected Controller (0.9.51) #132

New issue

Open

opened 2026-10-22 05:05:56 +00:00 by roman · 0 comments

roman commented 2026-10-22 05:05:56 +00:00

Owner

Copy link

Originally created by @J-A-McCrae on GitHub (Sep 10, 2026).
Original GitHub issue: https://github.com/safijari/openpuck/issues/285

Environment

• Windows 11
• Pop!_OS / Linux for direct scpair.py testing
• 4 × Steam Controller 2 units available
• 2 × OpenPucks available
• 4 × Official Valve pucks available for comparison
• OpenPuck firmware tested:
  • 0.9.51
  • 0.9.31
• OpenPuck factory-reset before controlled tests

Controller serials used:

FXA9954700038
FXA9961702619
FXA9954601063
FXA99622023A6

Primary OpenPuck:

FXB996025E5A9

Secondary OpenPuck:

FXB996024034D

---

Summary

There appear to be two related multi-controller problems when using Steam Controller 2 units with OpenPuck:

1. Steam can instantiate a single physical Steam Controller 2 multiple times when pairing additional controllers to OpenPuck.

   • In some earlier reproductions, the duplicated controller also appeared to overwrite or occupy multiple OpenPuck pairing slots.
   • In the latest controlled reproduction, however, the OpenPuck bond table remained completely correct while Steam still instantiated the second physical controller twice.

2. Even when bypassing Steam entirely and creating four correct independent bonds with scpair.py, OpenPuck only allows one controller to maintain a live RF connection at a time.

   • Each bonded controller works correctly when used individually.
   • A second bonded controller powered on while another controller is already connected fails to establish a simultaneous RF session.

Official Valve pucks do not show these behaviours with the same controllers.

The latest testing therefore suggests that bond storage itself is not the root cause. The fault appears more likely to involve OpenPuck's multi-controller RF/session handling and/or the way active controller sessions are exposed through its per-slot USB interfaces to Steam.

---

Initial Steam pairing reproduction

Starting from a factory-reset OpenPuck with all slots empty:

1. Pair Controller 1 through Steam.

   • One controller appears.
   • Pairing succeeds normally.

2. Pair Controller 2.

   • One controller appears.
   • Pairing succeeds normally.

3. Pair Controller 3.

   • Initially one controller appears in Steam.
   • After pairing, Steam shows Controller 3 three times.
   • Two additional entries are labelled Steam Controller Puck.
   • OpenPuck slots 1, 2 and 3 become associated with Controller 3.
   • Existing Controller 1 and Controller 2 pairings are overwritten.

I repeated the test using a different controller order:

1. Controller 3 first — normal.
2. Controller 4 second — normal.
3. Controller 1 third — Controller 1 then appears three times.

This initially suggested the fault followed the third pairing position rather than any particular controller.

Steam controller logs confirmed that the same physical controller serial was instantiated simultaneously as multiple wireless controller numbers.

---

Reproduction on a second OpenPuck

The duplication behaviour was also reproduced on a second OpenPuck.

On that unit, the failure occurred while pairing the second controller rather than the third.

This shows that:

• the problem is not tied to one particular OpenPuck;
• the trigger is not deterministically "the third controller";
• the failure appears state-dependent.

In this reproduction, the second controller was shown multiple times by Steam and the first controller's pairing appeared to be overwritten.

---

Control test with official Valve puck

The same four Steam Controller 2 units pair normally using official Valve pucks.

No duplication was observed through all four controllers.

The controllers themselves therefore do not appear to be the source of the problem.

---

Direct pairing test using scpair.py

To remove Steam from the pairing process entirely, I tested under Linux using OpenPuck's scpair.py.

OpenPuck was factory-reset and the relevant controller-side puck slots were cleared.

Using OpenPuck firmware 0.9.31 with the matching 0.9.31 source branch, four controllers were explicitly paired one-by-one to four separate OpenPuck slots:

slot 0 → FXA9954700038
key 7898c6ae451c8365

slot 1 → FXA9961702619
key 803fb08b941d4246

slot 2 → FXA9954601063
key b62ed28de42fed1f

slot 3 → FXA99622023A6
key d24dc6c14cfe36b3

Each controller's own controller-side slot contained the corresponding OpenPuck serial and exactly matching bond key.

The bond data was therefore valid and independent on both sides.

The OpenPuck was subsequently upgraded to firmware 0.9.51 without factory reset, and all four bond records survived intact.

Using the matching/current scpair.py, each wired controller independently reports the correct OpenPuck serial and corresponding bond key.

---

Individual wireless connection test

On firmware 0.9.51, with four correct bonds stored:

With no controllers powered on:

slot 0: FXA9954700038
slot 1: FXA9961702619
slot 2: FXA9954601063
slot 3: FXA99622023A6

No controller connected.

Powering on Controller 1 alone works correctly:

slot 0: FXA9954700038, connected to controller FXA9954700038
slot 1: FXA9961702619
slot 2: FXA9954601063
slot 3: FXA99622023A6

Powering on Controller 2 alone also works correctly:

slot 0: FXA9954700038
slot 1: FXA9961702619, connected to controller FXA9961702619
slot 2: FXA9954601063
slot 3: FXA99622023A6

The other controllers likewise work correctly when used individually.

---

Simultaneous wireless connection failure

If Controller 1 is powered on first, it connects normally.

If Controller 2 is then powered on while Controller 1 remains connected, Controller 2 powers on but never establishes a live RF connection.

scpair.py list continues to show only Controller 1:

slot 0: FXA9954700038, connected to controller FXA9954700038
slot 1: FXA9961702619
slot 2: FXA9954601063
slot 3: FXA99622023A6

Controller (wireless): FXA9954700038

There is no second wireless controller entry.

The same behaviour is visible in the OpenPuck web UI and in Steam on Windows:

• the first powered-on controller connects normally;
• subsequent bonded controllers power on;
• they do not establish an additional OpenPuck RF link;
• only the first controller remains active.

This reproduces independently of Steam's pairing mechanism.

---

Controlled Windows retest after HID/PnP cleanup

To rule out stale Windows HID/PnP state, all stale Valve VID_28DE devices were removed from Windows while all Valve hardware was disconnected.

Windows was then rebooted.

The secondary OpenPuck was:

• factory-reset;
• reflashed with OpenPuck 0.9.51;
• connected as the only puck under test.

Controller 1 and Controller 2 had their secondary controller-side pairing slots explicitly cleared using scpair.py.

The controllers were then paired one at a time through the Steam UI using those secondary slots.

Controller 1 paired normally.

When Controller 2 was paired, Steam again duplicated it.

This reproduction therefore occurred after:

• Windows Valve HID/PnP cleanup;
• reboot;
• OpenPuck factory reset;
• fresh 0.9.51 firmware;
• controller-side secondary slot cleanup.

Stale Windows HID devices are therefore unlikely to be the primary cause.

---

Important latest finding: duplication with a correct OpenPuck bond table

After the above clean reproduction, the secondary OpenPuck bond table was inspected directly under Linux:

Puck: FXB996024034D (OpenPuck), firmware 6A628359 (OpenPuck 0.9.51 f963e39e)

slot 0: FXA9954700038
        key 50b4b67e2c69a793

slot 1: FXA9961702619
        key 5fdf2592dede3fe6

slot 2: Empty

slot 3: Empty

This bond table is completely correct.

There is:

• one bond for Controller 1;
• one bond for Controller 2;
• no duplicate controller serial in another puck slot;
• no unexpected slot overwrite.

Despite this, Steam instantiated Controller 2 twice as two simultaneous wireless controllers.

Steam's controller log showed the same physical serial:

FXA9961702619

first as wireless Controller 0 and then, approximately four seconds later, as wireless Controller 1.

Both instances reported the same:

• controller serial;
• firmware;
• dongle version.

This demonstrates that Steam-side duplication can occur even when OpenPuck's persistent bond table is correct.

---

Linux runtime state after the duplicate Steam reproduction

With only Controller 2 powered wirelessly and the same OpenPuck connected to Linux, scpair.py list reported:

Puck: FXB996024034D (OpenPuck), firmware 6A628359 (OpenPuck 0.9.51 f963e39e)

slot 0: FXA9954700038
        key 50b4b67e2c69a793

slot 1: FXA9961702619
        key 5fdf2592dede3fe6
        connected to controller FXA9961702619

slot 2: Empty
slot 3: Empty

Controller (wireless): FXA9961702619

The controller itself reported:

slot 0: FXB996025E5A9
        key 025df9e7873da33e

slot 1: FXB996024034D
        key 5fdf2592dede3fe6

This is internally consistent:

• controller secondary slot points to the secondary OpenPuck;
• controller-side key exactly matches OpenPuck slot 1;
• OpenPuck reports one active controller;
• only OpenPuck slot 1 is reported active.

Therefore, in this latest reproduction, Linux does not show the controller simultaneously active on multiple OpenPuck slots, even though Steam on Windows instantiated it twice.

This suggests the Steam duplication can occur independently of persistent bond corruption and independently of an obviously duplicated RF session at the scpair.py level.

---

Earlier 0.9.51 multi-slot active-state anomaly

During earlier direct-pairing testing on firmware 0.9.51, there were also cases where one physical wireless controller appeared active through more than one populated OpenPuck slot.

For example:

slot 0: FXA9954700038, connected to controller FXA9961702619
slot 1: FXA9961702619, connected to controller FXA9961702619

In another state, when Controller 1 was powered on:

• slot 0 correctly identified Controller 1;
• another slot also appeared active;
• that second active interface returned no valid controller serial.

This caused the current scpair.py list implementation to encounter NoneType errors while attempting to interrogate the phantom active controller interface.

This behaviour is not reproduced in every test and may represent a separate or state-dependent active-interface routing problem.

It may nevertheless be related to the duplicate logical controllers observed by Steam.

---

Steam UI pairing indication is not reliable in this failure state

Steam's pairing-state UI also appears capable of disagreeing with the actual controller/OpenPuck state.

For example, Steam has reported that a controller was not paired while the controller was actively controlling the Windows mouse through gyro input.

Direct scpair.py inspection subsequently confirmed valid controller-side and OpenPuck-side bonds.

Therefore, for these tests I consider the following more authoritative than Steam's pairing-status UI:

1. controller-side bond data from scpair.py;
2. OpenPuck-side bond data from scpair.py;
3. OpenPuck connected to controller ... state;
4. observable live controller input.

Steam's displayed "paired/unpaired" status should therefore be treated as an additional symptom rather than reliable evidence of actual bond state.

---

Expected behaviour

OpenPuck exposes four independent bond slots and is intended to support multiple Steam Controller 2 units simultaneously:

Controller A → puck slot 0
Controller B → puck slot 1
Controller C → puck slot 2
Controller D → puck slot 3

Each bonded controller should be able to establish an independent RF session concurrently.

Each active controller should also be exposed to the host exactly once.

---

Actual behaviour

Persistent bond storage can be made fully correct.

Each controller can also connect correctly when tested individually.

However:

• only the first powered-on controller establishes a live RF session in direct multi-controller testing;
• subsequent bonded controllers fail to establish simultaneous RF connections;
• Steam can instantiate a single physical wireless controller more than once;
• this Steam duplication can occur even when the OpenPuck bond table contains exactly one correct bond for that controller;
• in some earlier states, one physical RF session has also appeared active through multiple OpenPuck slot interfaces;
• in other Steam pairing runs, duplicated controllers have coincided with apparent slot overwrites;
• Steam's own paired/unpaired UI can disagree with the actual live RF/bond state.

---

Current interpretation

The persistent pairing database does not appear to be the fundamental problem.

The direct scpair.py tests demonstrate that:

• independent bonds can be stored correctly;
• controller-side and puck-side serial/key pairs match;
• all controllers work individually;
• simultaneous RF operation still fails.

The latest Windows reproduction additionally demonstrates that Steam can duplicate one physical wireless controller even while the OpenPuck persistent bond table remains correct.

This suggests there may be two closely related runtime issues:

1. OpenPuck multi-controller RF/session handling

   • only one RF session remains active at a time;

2. Per-slot USB/active-session presentation to Steam

   • under some conditions, Steam receives or interprets a single physical controller as more than one logical wireless controller.

---

Likely areas to investigate

Useful areas to inspect may include:

• simultaneous RF session scheduling across populated slots;
• per-slot RF connection state;
• session-address assignment;
• handling of a second controller attempting to connect while another slot is already active;
• independent tracking of active state for each bond slot;
• mapping between RF sessions and MI_02–MI_05 puck HID interfaces;
• whether one RF session can be exposed through more than one host-facing slot interface;
• whether stale active state remains associated with another slot/interface after a pairing transition;
• whether Steam receives identical controller serials from more than one puck HID endpoint;
• whether the host-visible per-slot interface state differs from the internal bond table;
• why Steam can instantiate the same controller serial as two simultaneous wireless controller numbers even when scpair.py reports only one active OpenPuck slot.

The simultaneous-connection failure reproduces on Linux without Steam once multiple valid bonds are present, so the core multi-controller RF problem does not appear to require Steam.

The Steam duplication behaviour may be a second manifestation of incorrect per-slot runtime/interface state rather than incorrect persistent pairing data.

Originally created by @J-A-McCrae on GitHub (Sep 10, 2026). Original GitHub issue: https://github.com/safijari/openpuck/issues/285 ## Environment * Windows 11 * Pop!_OS / Linux for direct `scpair.py` testing * 4 × Steam Controller 2 units available * 2 × OpenPucks available * 4 × Official Valve pucks available for comparison * OpenPuck firmware tested: * 0.9.51 * 0.9.31 * OpenPuck factory-reset before controlled tests Controller serials used: ```text FXA9954700038 FXA9961702619 FXA9954601063 FXA99622023A6 ``` Primary OpenPuck: ```text FXB996025E5A9 ``` Secondary OpenPuck: ```text FXB996024034D ``` --- ## Summary There appear to be two related multi-controller problems when using Steam Controller 2 units with OpenPuck: 1. **Steam can instantiate a single physical Steam Controller 2 multiple times when pairing additional controllers to OpenPuck.** * In some earlier reproductions, the duplicated controller also appeared to overwrite or occupy multiple OpenPuck pairing slots. * In the latest controlled reproduction, however, the OpenPuck bond table remained completely correct while Steam still instantiated the second physical controller twice. 2. **Even when bypassing Steam entirely and creating four correct independent bonds with `scpair.py`, OpenPuck only allows one controller to maintain a live RF connection at a time.** * Each bonded controller works correctly when used individually. * A second bonded controller powered on while another controller is already connected fails to establish a simultaneous RF session. Official Valve pucks do not show these behaviours with the same controllers. The latest testing therefore suggests that bond storage itself is not the root cause. The fault appears more likely to involve OpenPuck's multi-controller RF/session handling and/or the way active controller sessions are exposed through its per-slot USB interfaces to Steam. --- ## Initial Steam pairing reproduction Starting from a factory-reset OpenPuck with all slots empty: 1. Pair Controller 1 through Steam. * One controller appears. * Pairing succeeds normally. 2. Pair Controller 2. * One controller appears. * Pairing succeeds normally. 3. Pair Controller 3. * Initially one controller appears in Steam. * After pairing, Steam shows Controller 3 three times. * Two additional entries are labelled `Steam Controller Puck`. * OpenPuck slots 1, 2 and 3 become associated with Controller 3. * Existing Controller 1 and Controller 2 pairings are overwritten. I repeated the test using a different controller order: 1. Controller 3 first — normal. 2. Controller 4 second — normal. 3. Controller 1 third — Controller 1 then appears three times. This initially suggested the fault followed the third pairing position rather than any particular controller. Steam controller logs confirmed that the same physical controller serial was instantiated simultaneously as multiple wireless controller numbers. --- ## Reproduction on a second OpenPuck The duplication behaviour was also reproduced on a second OpenPuck. On that unit, the failure occurred while pairing the second controller rather than the third. This shows that: * the problem is not tied to one particular OpenPuck; * the trigger is not deterministically "the third controller"; * the failure appears state-dependent. In this reproduction, the second controller was shown multiple times by Steam and the first controller's pairing appeared to be overwritten. --- ## Control test with official Valve puck The same four Steam Controller 2 units pair normally using official Valve pucks. No duplication was observed through all four controllers. The controllers themselves therefore do not appear to be the source of the problem. --- ## Direct pairing test using `scpair.py` To remove Steam from the pairing process entirely, I tested under Linux using OpenPuck's `scpair.py`. OpenPuck was factory-reset and the relevant controller-side puck slots were cleared. Using OpenPuck firmware 0.9.31 with the matching 0.9.31 source branch, four controllers were explicitly paired one-by-one to four separate OpenPuck slots: ```text slot 0 → FXA9954700038 key 7898c6ae451c8365 slot 1 → FXA9961702619 key 803fb08b941d4246 slot 2 → FXA9954601063 key b62ed28de42fed1f slot 3 → FXA99622023A6 key d24dc6c14cfe36b3 ``` Each controller's own controller-side slot contained the corresponding OpenPuck serial and exactly matching bond key. The bond data was therefore valid and independent on both sides. The OpenPuck was subsequently upgraded to firmware 0.9.51 without factory reset, and all four bond records survived intact. Using the matching/current `scpair.py`, each wired controller independently reports the correct OpenPuck serial and corresponding bond key. --- ## Individual wireless connection test On firmware 0.9.51, with four correct bonds stored: With no controllers powered on: ```text slot 0: FXA9954700038 slot 1: FXA9961702619 slot 2: FXA9954601063 slot 3: FXA99622023A6 No controller connected. ``` Powering on Controller 1 alone works correctly: ```text slot 0: FXA9954700038, connected to controller FXA9954700038 slot 1: FXA9961702619 slot 2: FXA9954601063 slot 3: FXA99622023A6 ``` Powering on Controller 2 alone also works correctly: ```text slot 0: FXA9954700038 slot 1: FXA9961702619, connected to controller FXA9961702619 slot 2: FXA9954601063 slot 3: FXA99622023A6 ``` The other controllers likewise work correctly when used individually. --- ## Simultaneous wireless connection failure If Controller 1 is powered on first, it connects normally. If Controller 2 is then powered on while Controller 1 remains connected, Controller 2 powers on but never establishes a live RF connection. `scpair.py list` continues to show only Controller 1: ```text slot 0: FXA9954700038, connected to controller FXA9954700038 slot 1: FXA9961702619 slot 2: FXA9954601063 slot 3: FXA99622023A6 Controller (wireless): FXA9954700038 ``` There is no second wireless controller entry. The same behaviour is visible in the OpenPuck web UI and in Steam on Windows: * the first powered-on controller connects normally; * subsequent bonded controllers power on; * they do not establish an additional OpenPuck RF link; * only the first controller remains active. This reproduces independently of Steam's pairing mechanism. --- ## Controlled Windows retest after HID/PnP cleanup To rule out stale Windows HID/PnP state, all stale Valve `VID_28DE` devices were removed from Windows while all Valve hardware was disconnected. Windows was then rebooted. The secondary OpenPuck was: * factory-reset; * reflashed with OpenPuck 0.9.51; * connected as the only puck under test. Controller 1 and Controller 2 had their secondary controller-side pairing slots explicitly cleared using `scpair.py`. The controllers were then paired one at a time through the Steam UI using those secondary slots. Controller 1 paired normally. When Controller 2 was paired, Steam again duplicated it. This reproduction therefore occurred after: * Windows Valve HID/PnP cleanup; * reboot; * OpenPuck factory reset; * fresh 0.9.51 firmware; * controller-side secondary slot cleanup. Stale Windows HID devices are therefore unlikely to be the primary cause. --- ## Important latest finding: duplication with a correct OpenPuck bond table After the above clean reproduction, the secondary OpenPuck bond table was inspected directly under Linux: ```text Puck: FXB996024034D (OpenPuck), firmware 6A628359 (OpenPuck 0.9.51 f963e39e) slot 0: FXA9954700038 key 50b4b67e2c69a793 slot 1: FXA9961702619 key 5fdf2592dede3fe6 slot 2: Empty slot 3: Empty ``` This bond table is completely correct. There is: * one bond for Controller 1; * one bond for Controller 2; * no duplicate controller serial in another puck slot; * no unexpected slot overwrite. Despite this, Steam instantiated Controller 2 twice as two simultaneous wireless controllers. Steam's controller log showed the same physical serial: ```text FXA9961702619 ``` first as wireless Controller 0 and then, approximately four seconds later, as wireless Controller 1. Both instances reported the same: * controller serial; * firmware; * dongle version. This demonstrates that Steam-side duplication can occur even when OpenPuck's persistent bond table is correct. --- ## Linux runtime state after the duplicate Steam reproduction With only Controller 2 powered wirelessly and the same OpenPuck connected to Linux, `scpair.py list` reported: ```text Puck: FXB996024034D (OpenPuck), firmware 6A628359 (OpenPuck 0.9.51 f963e39e) slot 0: FXA9954700038 key 50b4b67e2c69a793 slot 1: FXA9961702619 key 5fdf2592dede3fe6 connected to controller FXA9961702619 slot 2: Empty slot 3: Empty Controller (wireless): FXA9961702619 ``` The controller itself reported: ```text slot 0: FXB996025E5A9 key 025df9e7873da33e slot 1: FXB996024034D key 5fdf2592dede3fe6 ``` This is internally consistent: * controller secondary slot points to the secondary OpenPuck; * controller-side key exactly matches OpenPuck slot 1; * OpenPuck reports one active controller; * only OpenPuck slot 1 is reported active. Therefore, in this latest reproduction, Linux does **not** show the controller simultaneously active on multiple OpenPuck slots, even though Steam on Windows instantiated it twice. This suggests the Steam duplication can occur independently of persistent bond corruption and independently of an obviously duplicated RF session at the `scpair.py` level. --- ## Earlier 0.9.51 multi-slot active-state anomaly During earlier direct-pairing testing on firmware 0.9.51, there were also cases where one physical wireless controller appeared active through more than one populated OpenPuck slot. For example: ```text slot 0: FXA9954700038, connected to controller FXA9961702619 slot 1: FXA9961702619, connected to controller FXA9961702619 ``` In another state, when Controller 1 was powered on: * slot 0 correctly identified Controller 1; * another slot also appeared active; * that second active interface returned no valid controller serial. This caused the current `scpair.py list` implementation to encounter `NoneType` errors while attempting to interrogate the phantom active controller interface. This behaviour is not reproduced in every test and may represent a separate or state-dependent active-interface routing problem. It may nevertheless be related to the duplicate logical controllers observed by Steam. --- ## Steam UI pairing indication is not reliable in this failure state Steam's pairing-state UI also appears capable of disagreeing with the actual controller/OpenPuck state. For example, Steam has reported that a controller was not paired while the controller was actively controlling the Windows mouse through gyro input. Direct `scpair.py` inspection subsequently confirmed valid controller-side and OpenPuck-side bonds. Therefore, for these tests I consider the following more authoritative than Steam's pairing-status UI: 1. controller-side bond data from `scpair.py`; 2. OpenPuck-side bond data from `scpair.py`; 3. OpenPuck `connected to controller ...` state; 4. observable live controller input. Steam's displayed "paired/unpaired" status should therefore be treated as an additional symptom rather than reliable evidence of actual bond state. --- ## Expected behaviour OpenPuck exposes four independent bond slots and is intended to support multiple Steam Controller 2 units simultaneously: ```text Controller A → puck slot 0 Controller B → puck slot 1 Controller C → puck slot 2 Controller D → puck slot 3 ``` Each bonded controller should be able to establish an independent RF session concurrently. Each active controller should also be exposed to the host exactly once. --- ## Actual behaviour Persistent bond storage can be made fully correct. Each controller can also connect correctly when tested individually. However: * only the first powered-on controller establishes a live RF session in direct multi-controller testing; * subsequent bonded controllers fail to establish simultaneous RF connections; * Steam can instantiate a single physical wireless controller more than once; * this Steam duplication can occur even when the OpenPuck bond table contains exactly one correct bond for that controller; * in some earlier states, one physical RF session has also appeared active through multiple OpenPuck slot interfaces; * in other Steam pairing runs, duplicated controllers have coincided with apparent slot overwrites; * Steam's own paired/unpaired UI can disagree with the actual live RF/bond state. --- ## Current interpretation The persistent pairing database does not appear to be the fundamental problem. The direct `scpair.py` tests demonstrate that: * independent bonds can be stored correctly; * controller-side and puck-side serial/key pairs match; * all controllers work individually; * simultaneous RF operation still fails. The latest Windows reproduction additionally demonstrates that Steam can duplicate one physical wireless controller even while the OpenPuck persistent bond table remains correct. This suggests there may be two closely related runtime issues: 1. **OpenPuck multi-controller RF/session handling** * only one RF session remains active at a time; 2. **Per-slot USB/active-session presentation to Steam** * under some conditions, Steam receives or interprets a single physical controller as more than one logical wireless controller. --- ## Likely areas to investigate Useful areas to inspect may include: * simultaneous RF session scheduling across populated slots; * per-slot RF connection state; * session-address assignment; * handling of a second controller attempting to connect while another slot is already active; * independent tracking of active state for each bond slot; * mapping between RF sessions and `MI_02`–`MI_05` puck HID interfaces; * whether one RF session can be exposed through more than one host-facing slot interface; * whether stale active state remains associated with another slot/interface after a pairing transition; * whether Steam receives identical controller serials from more than one puck HID endpoint; * whether the host-visible per-slot interface state differs from the internal bond table; * why Steam can instantiate the same controller serial as two simultaneous wireless controller numbers even when `scpair.py` reports only one active OpenPuck slot. The simultaneous-connection failure reproduces on Linux without Steam once multiple valid bonds are present, so the core multi-controller RF problem does not appear to require Steam. The Steam duplication behaviour may be a second manifestation of incorrect per-slot runtime/interface state rather than incorrect persistent pairing data.

roman referenced this issue 2026-10-22 05:07:46 +00:00

[PR #132] [MERGED] fix: include lizard map in backup and guard pre-lizard-mode restore #217

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

copilot/add-power-off-controller-when-charging

fix-lizard-dropped-reports

copilot/304

copilot/291

low-signal-polling

copilot/292

switch2pro

fix-playstation-modes

firmware

pr-247-fixes

copilot/246-feature-update

picopuck

HID-and-Sinput

bmac

fix-haptic-pulse-0x81

switch-gyro-config

copilot/170-add-controller-mapping

reconnect-issue-regression-fix

copilot/update-cfg-tud-hid-to-6

mode-announce

fix-stuck-input-when-changing-modes

rumble-scale

fix-switch-rumble-decode

full-wipe-mode

copilot/add-disable-rumble-option

fix-lizard-mode-grip-issue

copilot/update-switch-pro-mode

copilot/mouse-smoothness-issue

copilot/fix-restoring-config-failure

copilot/handle-puck-reconnection

fix-firmware-patcher

ble-test

copilot/review-125

copilot/gate-firmware-update-tab

copilot/add-remap-pure-lizard-mode-shortcuts

copilot/flash-uf2-from-webusb

copilot/fix-mouse-smoothness-openpuck

disabling-haptics-in-emulated-modes

copilot/resetreas-hex-value

copilot/review-119

copilot/compile-uf2-files

copilot/114-fortnite-ds5-controller-issue

copilot/save-hex-files-as-artifacts

copilot/tag-version-091

fix-haptics-regression

july-1-beta-update-compat

copilot/compare-main-commit-bf4c099

fix/lizard-multi-controller

ps3

stability-fix-refactor

stability-fix

zephyr-migration

attempt-at-fixing-connects

copilot/add-ps3-mode-gyro-haptics

copilot/discussion-72-reasons-solutions

copilot/add-slider-for-controller-mode

controller-emu

fix/buzz-link-stability

modern-standby-wake-fix

copilot/attach-hid-mouse-for-switch-pro-mode

steam-battery-fix

separate-configs-haptics-toggle-etc

copilot/feature78-ab-swap-nintendo-switch

multiple-controllers

more-closely-match-real-puck-comms

update-sniffer

copilot/fix-ci-uf2-upload

easier-dfu

switch-2-mouse-mode

stuck-haptics-another-attempt

ps5-ps4-fixes

cull-comments

formatter

copilot/fix-controller-disconnection-issue

copilot/fix-steam-battery-display-issue

steam-y-shutdown-global

switch-pro-mode-real-console

copilot/43

rumble

ds4-5-fixes-qam-mappings

lizard-maps-qam-maps-gyro-fix

bugfixes-mid-june-2026

led-poweroff-battery

more-buzz-and-quit

updated-docs

copilot/20

copilot/17

rearchitecture

new-controllers

copilot/11

weird-haptics-fix

initial_commit

0.9.67

0.9.66

0.9.65

0.9.64

0.9.63

0.9.62

0.9.61

0.9.60

0.9.59

0.9.58

0.9.57

0.9.56

0.9.55

0.9.54

0.9.53

0.9.52

0.9.51

0.9.50

0.9.49

0.9.48

0.9.47

0.9.46

0.9.45

0.9.44

0.9.43

0.9.42

0.9.41

0.9.40

0.9.39

0.9.38

0.9.37

0.9.36

0.9.35

0.9.34

0.9.33

0.9.32

0.9.31

0.9.30

0.9.29

0.9.28

0.9.27

0.9.26

0.9.25

0.9.24

0.9.23

0.9.22

0.9.21

0.9.20

0.9.19

0.9.18

0.9.17

0.9.16

0.9.15

0.9.14

0.9.13

0.9.12

0.9.11

0.9.10

0.9.9

0.9.8

0.9.7

0.9.4

0.9.6

0.9.3

0.9.2

0.9.1

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

  

wontfix

No labels

pull-request

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

safijari/openpuck#132

No description provided.