[PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[Arthur Crepin-Leblond]

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

[PATCH BlueZ 1/1] device: Expose the disconnect reason over D-Bus

[Arthur Crepin-Leblond]

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

RE: Expose the disconnect reason over D-Bus

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

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

Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[Bastien Nocera]

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?

Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[Arthur Crepin-Leblond]

On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@hadess.net> 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.

Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[Luiz Augusto von Dentz]

Hi Arthur,

On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond
<arthur@marmottus.net> wrote:
>
> On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@hadess.net> 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

Re: [PATCH BlueZ 0/1] Expose the disconnect reason over D-Bus

[Arthur Crepin-Leblond]

On Tuesday, December 13, 2022 21:45 CET, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> Hi Arthur,
>
> On Mon, Dec 12, 2022 at 7:38 AM Arthur Crepin-Leblond
> <arthur@marmottus.net> wrote:
> >
> > On Monday, December 12, 2022 15:49 CET, Bastien Nocera <hadess@hadess.net> 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