Skip to content

*: detecting abrupt disconnections in Linux#420

Closed
sorayaormazabalmayo wants to merge 10 commits intotinygo-org:releasefrom
saltosystems:feature/detect-abrupt-disconnection
Closed

*: detecting abrupt disconnections in Linux#420
sorayaormazabalmayo wants to merge 10 commits intotinygo-org:releasefrom
saltosystems:feature/detect-abrupt-disconnection

Conversation

@sorayaormazabalmayo
Copy link

This PR implements persistent D-Bus signal monitoring at the adapter level to detect abrupt disconnections. The connectHandler callback was not being invoked when Bluetooth devices disconnected abruptly (e.g., device powered off, out of range, battery died) on Linux. It only worked for planned disconnections via Device.Disconnect(). This created an inconsistency with the Darwin implementation, which correctly detects all disconnections through CoreBluetooth's DidDisconnectPeripheral delegate method.

gen2thomas and others added 10 commits January 12, 2026 10:02
This PR registers a `ConnectionStatusChanged` WinRT event handler on
`BluetoothLEDevice` to detect abrupt disconnections. The handler
resolves the current connection state and forwards it to
`a.connectHandler`. The event token and handler are stored to allow
proper unregistration during device teardown.
notifications by passing in nil as the callback argument
…inygo-org#389)

* linux: Add Write method to write characteristic value with response

* Use short hand error check

* Remove named returns
* linux: support removing service

* windows: support removing service

* sd+hci: stub removing service method
Unexpose the representation of the UUID data and unexport the Bytes
method. Also document the byte ordering of binary marshaling and provide
an exported binary round-tripper for UUID data.
Signed-off-by: deadprogram <ron@hybridgroup.com>
…go-org#410)

* fix: Windows characteristic ordering in DiscoverCharacteristics

The characteristics will now appear on the expected order

* range over filterUUIDs
This PR implements persistent D-Bus signal monitoring at the adapter
level to detect abrupt disconnections. The `connectHandler` callback was
not being invoked when Bluetooth devices disconnected abruptly (e.g.,
device powered off, out of range, battery died) on Linux. It only worked
for planned disconnections via `Device.Disconnect()`. This created an
inconsistency with the Darwin implementation, which correctly detects
all disconnections through CoreBluetooth's `DidDisconnectPeripheral`
delegate method.
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.

9 participants