Problem
The app enumerates the foot switch and configures the listener once at launch
(AppDelegate.applicationDidFinishLaunching). It does not react to devices being
added or removed while running:
- USB: plugging/unplugging the pedal is not noticed.
- Bluetooth: connecting/disconnecting the FS17Pro is not noticed.
So the Settings device row (detected / config-verify) and the menu state reflect
only what was present at launch, and a user who switches the FS17Pro between USB and
Bluetooth modes after launch sees stale status until they relaunch.
(The runtime key listener itself is a global event tap and keeps working
regardless — this is specifically about device detection/status and any
transport-dependent programming UI being stale.)
Desired behavior
React to device add/remove live:
- USB: register IOKit HID matching/removal callbacks
(IOHIDManagerRegisterDeviceMatchingCallback /
IOHIDManagerRegisterDeviceRemovalCallback) instead of a one-shot
IOHIDManagerCopyDevices, and refresh detection/status when they fire.
- Bluetooth: observe CoreBluetooth connect/disconnect
(centralManager(_:didConnect:) / didDisconnectPeripheral) or re-query
retrieveConnectedPeripherals on a trigger, and refresh.
- Refresh the Settings device row and any transport-dependent state when the
connected transport changes (e.g. user switches the FS17Pro from USB to BLE).
Notes / relationship to current work
- Detection currently lives in
FootswitchHIDController (USB IOKit) and
BLEPedalProgrammer (CoreBluetooth, on-demand).
- The FS17Pro work adds transport-keyed trigger config and transport-aware
programming (program writes the key for the currently-connected transport).
Live transport detection would make that programming target update automatically
when the user switches modes, instead of depending on launch-time state /
manual Settings refresh.
Deferred from the FS17Pro Bluetooth support work.
Problem
The app enumerates the foot switch and configures the listener once at launch
(
AppDelegate.applicationDidFinishLaunching). It does not react to devices beingadded or removed while running:
So the Settings device row (detected / config-verify) and the menu state reflect
only what was present at launch, and a user who switches the FS17Pro between USB and
Bluetooth modes after launch sees stale status until they relaunch.
(The runtime key listener itself is a global event tap and keeps working
regardless — this is specifically about device detection/status and any
transport-dependent programming UI being stale.)
Desired behavior
React to device add/remove live:
(
IOHIDManagerRegisterDeviceMatchingCallback/IOHIDManagerRegisterDeviceRemovalCallback) instead of a one-shotIOHIDManagerCopyDevices, and refresh detection/status when they fire.(
centralManager(_:didConnect:)/didDisconnectPeripheral) or re-queryretrieveConnectedPeripheralson a trigger, and refresh.connected transport changes (e.g. user switches the FS17Pro from USB to BLE).
Notes / relationship to current work
FootswitchHIDController(USB IOKit) andBLEPedalProgrammer(CoreBluetooth, on-demand).programming (program writes the key for the currently-connected transport).
Live transport detection would make that programming target update automatically
when the user switches modes, instead of depending on launch-time state /
manual Settings refresh.
Deferred from the FS17Pro Bluetooth support work.