Skip to content

Request controller removal for Bluetooth disconnect special actions - #132

Merged
hbashton merged 1 commit into
hbashton:mainfrom
meiameiameia:fix/remove-controller-after-special-action
Oct 9, 2026
Merged

hbashton merged 1 commit into
hbashton:mainfrom
meiameiameia:fix/remove-controller-after-special-action

Conversation

@meiameiameia

Copy link
Copy Markdown
Contributor

Addresses #122.

The Bluetooth DisconnectBT special action calls DisconnectBT() without requesting removal. For DualSense, manual disconnect retires the read worker before disconnecting the radio, so a later HID read failure cannot be relied on to remove the old controller from DS4Windows. The controller can remain listed and require Stop/Start before reconnecting.

Pass callRemoval: true from the special-action dispatcher, matching the existing controller-list and tray disconnect paths. The synced, charging and Bluetooth guards remain unchanged; the Sony wireless adapter path is unchanged.

Validation:

  • Extended the existing DualSense lifecycle fixture to invoke the real special-action dispatcher on the command worker. It checks one removal, UI row cleanup, worker retirement before the radio request, reentrant cleanup, preservation of another controller and survival of a replacement connection when an old removal arrives late.
  • Added guard cases for charging, unsynced state, USB and an incomplete trigger combination. The manual-disconnect fixture now runs 8 cases; 4 related command-worker lifecycle tests also pass.
  • Two new regression cases failed before the production fix.
  • Release x64 build succeeded; 404 related tests passed in combined local validation, including the separate touchpad fix. Both patches apply independently to main at 3650240.
  • Tests use in-memory settings and synthetic controllers whose radio/HID operations are overridden. No live controller, driver or backend was launched.

Hardware follow-up for someone with a DualSense over Bluetooth: trigger the PS+Options disconnect action, press PS to reconnect without Stop/Start, and verify one controller row and one output. Repeat three times; if a second controller is available, confirm it keeps working. Physical Bluetooth reconnection has not been validated locally.

No equivalent open PR was found for this dispatcher call. This PR is independent of #129 and #130 and makes no VIIPER backend changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants