Hello,
I am trying to expose the device disconnect reason over D-Bus and the
most elegant way I found was to subscribe to the adapter notify
callback that gives the reason as an argument.
Arthur Crepin-Leblond (1):
device: Expose the disconnect reason over D-Bus
src/device.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
--
2.38.1
Get the disconnect reason from the adapter disconnect notify callback
and set the D-Bus "DisconnectReason" property.
---
src/device.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/src/device.c b/src/device.c
index 995d39f2c..395cbe3e5 100644
--- a/src/device.c
+++ b/src/device.c
@@ -183,6 +183,7 @@ struct btd_device {
bool le;
bool pending_paired; /* "Paired" waiting for SDP */
bool svc_refreshed;
+ uint8_t disconnect_reason;
bool refresh_discovery;
/* Manage whether this device can wake the system from suspend.
@@ -1134,6 +1135,18 @@ dev_property_get_svc_resolved(const GDBusPropertyTable *property,
return TRUE;
}
+static gboolean
+dev_property_get_disconnect_reason(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct btd_device *device = data;
+ guint8 val = device->disconnect_reason;
+
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_BYTE, &val);
+
+ return TRUE;
+}
+
static gboolean dev_property_flags_exist(const GDBusPropertyTable *property,
void *data)
{
@@ -2624,6 +2637,14 @@ static void device_set_svc_refreshed(struct btd_device *device, bool value)
DEVICE_INTERFACE, "ServicesResolved");
}
+static void btd_device_disconnected_cb(struct btd_device *device, uint8_t reason)
+{
+ device->disconnect_reason = reason;
+
+ g_dbus_emit_property_changed(dbus_conn, device->path,
+ DEVICE_INTERFACE, "DisconnectReason");
+}
+
static void device_svc_resolved(struct btd_device *dev, uint8_t browse_type,
uint8_t bdaddr_type, int err)
{
@@ -2987,6 +3008,7 @@ static const GDBusPropertyTable device_properties[] = {
{ "TxPower", "n", dev_property_get_tx_power, NULL,
dev_property_exists_tx_power },
{ "ServicesResolved", "b", dev_property_get_svc_resolved, NULL, NULL },
+ { "DisconnectReason", "y", dev_property_get_disconnect_reason, NULL, NULL },
{ "AdvertisingFlags", "ay", dev_property_get_flags, NULL,
dev_property_flags_exist,
G_DBUS_PROPERTY_FLAG_EXPERIMENTAL},
@@ -3910,6 +3932,8 @@ static struct btd_device *device_new(struct btd_adapter *adapter,
return NULL;
}
+ device->disconnect_reason = MGMT_DEV_DISCONN_UNKNOWN;
+
memset(device->ad_flags, INVALID_FLAGS, sizeof(device->ad_flags));
device->ad = bt_ad_new();
@@ -6910,11 +6934,13 @@ void btd_device_init(void)
dbus_conn = btd_get_dbus_connection();
service_state_cb_id = btd_service_add_state_cb(
service_state_changed, NULL);
+ btd_add_disconnect_cb(btd_device_disconnected_cb);
}
void btd_device_cleanup(void)
{
btd_service_remove_state_cb(service_state_cb_id);
+ btd_remove_disconnect_cb(btd_device_disconnected_cb);
}
void btd_device_set_volume(struct btd_device *device, int8_t volume)
--
2.38.1
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=703845
---Test result---
Test Summary:
CheckPatch FAIL 0.79 seconds
GitLint PASS 0.34 seconds
BuildEll PASS 27.63 seconds
BluezMake PASS 1018.21 seconds
MakeCheck PASS 11.85 seconds
MakeDistcheck PASS 149.74 seconds
CheckValgrind PASS 247.21 seconds
bluezmakeextell PASS 97.21 seconds
IncrementalBuild PASS 855.05 seconds
ScanBuild PASS 1064.30 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ,1/1] device: Expose the disconnect reason over D-Bus
WARNING:LONG_LINE: line length of 81 exceeds 80 columns
#98: FILE: src/device.c:2640:
+static void btd_device_disconnected_cb(struct btd_device *device, uint8_t reason)
WARNING:LONG_LINE: line length of 84 exceeds 80 columns
#113: FILE: src/device.c:3011:
+ { "DisconnectReason", "y", dev_property_get_disconnect_reason, NULL, NULL },
/github/workspace/src/src/13071144.patch total: 0 errors, 2 warnings, 67 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13071144.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---
Regards,
Linux Bluetooth
On Mon, 2022-12-12 at 14:32 +0100, Arthur Crepin-Leblond wrote:
> Hello,
>
> I am trying to expose the device disconnect reason over D-Bus and the
> most elegant way I found was to subscribe to the adapter notify
> callback that gives the reason as an argument.
Any reason why this can't be a signal with the reason as an argument?
On Monday, December 12, 2022 15:49 CET, Bastien Nocera <[email protected]> wrote:
> On Mon, 2022-12-12 at 14:32 +0100, Arthur Crepin-Leblond wrote:
> > Hello,
> >
> > I am trying to expose the device disconnect reason over D-Bus and the
> > most elegant way I found was to subscribe to the adapter notify
> > callback that gives the reason as an argument.
>
> Any reason why this can't be a signal with the reason as an argument?
I chose the easy path by copying the existing code for the device properties
that get updated like the "Connected" or "ServicesResolved".
I am not too familiar with BlueZ signals other than PropertiesChanged,
InterfacesRemoved/Added. What would you have in mind?
And apologies in advance, it's my first time submitting here, I do not have
an advanced knowledge of the BlueZ internals.
Hi Arthur,
On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond
<[email protected]> wrote:
>
> On Monday, December 12, 2022 15:49 CET, Bastien Nocera <[email protected]> wrote:
>
> > On Mon, 2022-12-12 at 14:32 +0100, Arthur Crepin-Leblond wrote:
> > > Hello,
> > >
> > > I am trying to expose the device disconnect reason over D-Bus and the
> > > most elegant way I found was to subscribe to the adapter notify
> > > callback that gives the reason as an argument.
> >
> > Any reason why this can't be a signal with the reason as an argument?
>
> I chose the easy path by copying the existing code for the device properties
> that get updated like the "Connected" or "ServicesResolved".
> I am not too familiar with BlueZ signals other than PropertiesChanged,
> InterfacesRemoved/Added. What would you have in mind?
>
> And apologies in advance, it's my first time submitting here, I do not have
> an advanced knowledge of the BlueZ internals.
Can you explain what is the use case here? I hope it is not to
reimplement something like the reconnect policy:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n281
--
Luiz Augusto von Dentz
On Tuesday, December 13, 2022 21:45 CET, Luiz Augusto von Dentz <[email protected]> wrote:
> Hi Arthur,
>
> On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond
> <[email protected]> wrote:
> >
> > On Monday, December 12, 2022 15:49 CET, Bastien Nocera <[email protected]> wrote:
> >
> > > On Mon, 2022-12-12 at 14:32 +0100, Arthur Crepin-Leblond wrote:
> > > > Hello,
> > > >
> > > > I am trying to expose the device disconnect reason over D-Bus and the
> > > > most elegant way I found was to subscribe to the adapter notify
> > > > callback that gives the reason as an argument.
> > >
> > > Any reason why this can't be a signal with the reason as an argument?
> >
> > I chose the easy path by copying the existing code for the device properties
> > that get updated like the "Connected" or "ServicesResolved".
> > I am not too familiar with BlueZ signals other than PropertiesChanged,
> > InterfacesRemoved/Added. What would you have in mind?
> >
> > And apologies in advance, it's my first time submitting here, I do not have
> > an advanced knowledge of the BlueZ internals.
>
> Can you explain what is the use case here? I hope it is not to
> reimplement something like the reconnect policy:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n281
>
>
> --
> Luiz Augusto von Dentz
Hi Luiz,
No, nothing to do with the reconnect policy.
My device (a Raspberry Pi) is acting as a central and is losing randomly
the connection with a device.
So, the use case is purely to be able to have information about the
disconnection.
--
Arthur Crepin-Leblond