[PATCH v2 0/2] Expose AdvertisingDataFlags in Device API

[PATCH v2 0/2] Expose AdvertisingDataFlags in Device API

[puthik]

From: Puthikorn Voravootivat <puthik@chromium.org>

The following patches expose AdvertisingFlags in Device API.
This is need by Android app on ChromeOS as Android normally
should get Advertising data flag from Bluetooth adapter.

v2:
Address Marcel's review to make it more future proof by making it array{byte}.
device->flags is still a uint8 because 1) We don't need it to be bigger now.
and 2) We can easily changed it to bigger type when needed without affecting
the DBus Device API.

Puthikorn Voravootivat (2):
  doc/device-api: Add AdvertisingFlags
  core: Add implementation of AdvertisingFlags

 doc/device-api.txt |  4 ++++
 src/adapter.c      |  2 ++
 src/device.c       | 36 ++++++++++++++++++++++++++++++++++++
 src/device.h       |  1 +
 4 files changed, 43 insertions(+)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 0/2] Expose AdvertisingDataFlags in Device API

[puthik]

From: Puthikorn Voravootivat <puthik@chromium.org>

The following patches expose AdvertisingFlags in Device API.
This is need by Android app on ChromeOS as Android normally
should get Advertising data flag from Bluetooth adapter.

v2:
Address Marcel's review to make it more future proof by making it array{byte}.
device->flags is still a uint8 because 1) We don't need it to be bigger now.
and 2) We can easily changed it to bigger type when needed without affecting
the DBus Device API.

Puthikorn Voravootivat (2):
  doc/device-api: Add AdvertisingFlags
  core: Add implementation of AdvertisingFlags

 doc/device-api.txt |  4 ++++
 src/adapter.c      |  2 ++
 src/device.c       | 36 ++++++++++++++++++++++++++++++++++++
 src/device.h       |  1 +
 4 files changed, 43 insertions(+)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[puthik]

From: Puthikorn Voravootivat <puthik@chromium.org>

This exposed Advertising Flags to BlueZ Device API

Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
---
 doc/device-api.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/device-api.txt b/doc/device-api.txt
index f5cac49..1985698 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -230,3 +230,7 @@ Properties	string Address [readonly]
 
 			Indicate whether or not service discovery has been
 			resolved.
+
+		array{byte} AdvertisingFlags [readonly]
+
+			The Advertising Data Flags of the remote device.
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 2/2] core: Add implementation of AdvertisingFlags

[puthik]

From: Puthikorn Voravootivat <puthik@chromium.org>

This adds 'AdvertisingFlags' property to Device interface.

Bluetooth Core Supplementary Spec v6 Chapter 1.3 defines Bluetooth
Flags as one of the data in advertise data. BlueZ also correctly
parses this data but never exposes it to upper layer.

Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
---
 src/adapter.c |  2 ++
 src/device.c  | 36 ++++++++++++++++++++++++++++++++++++
 src/device.h  |  1 +
 3 files changed, 39 insertions(+)

diff --git a/src/adapter.c b/src/adapter.c
index b096d48..1abb5c0 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -5552,6 +5552,8 @@ static void update_found_devices(struct btd_adapter *adapter,
 	if (eir_data.sd_list)
 		device_set_service_data(dev, eir_data.sd_list);
 
+	device_set_flags(dev, eir_data.flags);
+
 	eir_data_free(&eir_data);
 
 	/*
diff --git a/src/device.c b/src/device.c
index fb6104f..993b8e7 100644
--- a/src/device.c
+++ b/src/device.c
@@ -247,6 +247,8 @@ struct btd_device {
 
 	GIOChannel	*att_io;
 	guint		store_id;
+
+	uint8_t         flags;
 };
 
 static const uint16_t uuid_list[] = {
@@ -939,6 +941,23 @@ dev_property_get_svc_resolved(const GDBusPropertyTable *property,
 	return TRUE;
 }
 
+static gboolean
+dev_property_get_flags(const GDBusPropertyTable *property,
+					DBusMessageIter *iter, void *data)
+{
+	struct btd_device *device = data;
+	uint8_t flags[] = { device->flags };
+	DBusMessageIter array;
+
+	dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
+					DBUS_TYPE_BYTE_AS_STRING, &array);
+	dbus_message_iter_append_fixed_array(&array, DBUS_TYPE_BYTE,
+						&flags, sizeof(flags));
+	dbus_message_iter_close_container(iter, &array);
+
+	return TRUE;
+}
+
 static gboolean dev_property_get_trusted(const GDBusPropertyTable *property,
 					DBusMessageIter *iter, void *data)
 {
@@ -2534,6 +2553,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 },
+	{ "AdvertisingFlags", "ay", dev_property_get_flags },
 
 	{ }
 };
@@ -5221,6 +5241,22 @@ void device_set_tx_power(struct btd_device *device, int8_t tx_power)
 						DEVICE_INTERFACE, "TxPower");
 }
 
+void device_set_flags(struct btd_device *device, uint8_t flags)
+{
+	if (!device)
+		return;
+
+	DBG("flags %d", flags);
+
+	if (device->flags == flags)
+		return;
+
+	device->flags = flags;
+
+	g_dbus_emit_property_changed(dbus_conn, device->path,
+					DEVICE_INTERFACE, "AdvertisingFlags");
+}
+
 static gboolean start_discovery(gpointer user_data)
 {
 	struct btd_device *device = user_data;
diff --git a/src/device.h b/src/device.h
index 387f598..93a159a 100644
--- a/src/device.h
+++ b/src/device.h
@@ -97,6 +97,7 @@ void device_set_rssi_with_delta(struct btd_device *device, int8_t rssi,
 							int8_t delta_threshold);
 void device_set_rssi(struct btd_device *device, int8_t rssi);
 void device_set_tx_power(struct btd_device *device, int8_t tx_power);
+void device_set_flags(struct btd_device *device, uint8_t flags);
 bool btd_device_is_connected(struct btd_device *dev);
 uint8_t btd_device_get_bdaddr_type(struct btd_device *dev);
 bool device_is_retrying(struct btd_device *device);
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[Luiz Augusto von Dentz]

Hi,

On Tue, Oct 18, 2016 at 10:10 PM,  <puthik@chromium.org> wrote:
> From: Puthikorn Voravootivat <puthik@chromium.org>
>
> This exposed Advertising Flags to BlueZ Device API
>
> Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
> ---
>  doc/device-api.txt | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index f5cac49..1985698 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -230,3 +230,7 @@ Properties  string Address [readonly]
>
>                         Indicate whether or not service discovery has been
>                         resolved.
> +
> +               array{byte} AdvertisingFlags [readonly]
> +
> +                       The Advertising Data Flags of the remote device.

It should probably be marked as experimental for now.

-- 
Luiz Augusto von Dentz

Re: [PATCH v2 2/2] core: Add implementation of AdvertisingFlags

[Luiz Augusto von Dentz]

Hi,

On Tue, Oct 18, 2016 at 10:11 PM,  <puthik@chromium.org> wrote:
> From: Puthikorn Voravootivat <puthik@chromium.org>
>
> This adds 'AdvertisingFlags' property to Device interface.
>
> Bluetooth Core Supplementary Spec v6 Chapter 1.3 defines Bluetooth
> Flags as one of the data in advertise data. BlueZ also correctly
> parses this data but never exposes it to upper layer.
>
> Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
> ---
>  src/adapter.c |  2 ++
>  src/device.c  | 36 ++++++++++++++++++++++++++++++++++++
>  src/device.h  |  1 +
>  3 files changed, 39 insertions(+)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index b096d48..1abb5c0 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -5552,6 +5552,8 @@ static void update_found_devices(struct btd_adapter *adapter,
>         if (eir_data.sd_list)
>                 device_set_service_data(dev, eir_data.sd_list);
>
> +       device_set_flags(dev, eir_data.flags);
> +
>         eir_data_free(&eir_data);
>
>         /*
> diff --git a/src/device.c b/src/device.c
> index fb6104f..993b8e7 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -247,6 +247,8 @@ struct btd_device {
>
>         GIOChannel      *att_io;
>         guint           store_id;
> +
> +       uint8_t         flags;
>  };
>
>  static const uint16_t uuid_list[] = {
> @@ -939,6 +941,23 @@ dev_property_get_svc_resolved(const GDBusPropertyTable *property,
>         return TRUE;
>  }
>
> +static gboolean
> +dev_property_get_flags(const GDBusPropertyTable *property,
> +                                       DBusMessageIter *iter, void *data)
> +{
> +       struct btd_device *device = data;
> +       uint8_t flags[] = { device->flags };
> +       DBusMessageIter array;
> +
> +       dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
> +                                       DBUS_TYPE_BYTE_AS_STRING, &array);
> +       dbus_message_iter_append_fixed_array(&array, DBUS_TYPE_BYTE,
> +                                               &flags, sizeof(flags));
> +       dbus_message_iter_close_container(iter, &array);
> +
> +       return TRUE;
> +}
> +
>  static gboolean dev_property_get_trusted(const GDBusPropertyTable *property,
>                                         DBusMessageIter *iter, void *data)
>  {
> @@ -2534,6 +2553,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 },
> +       { "AdvertisingFlags", "ay", dev_property_get_flags },

It shall have experimental flag set for now.

>
>         { }
>  };
> @@ -5221,6 +5241,22 @@ void device_set_tx_power(struct btd_device *device, int8_t tx_power)
>                                                 DEVICE_INTERFACE, "TxPower");
>  }
>
> +void device_set_flags(struct btd_device *device, uint8_t flags)
> +{
> +       if (!device)
> +               return;
> +
> +       DBG("flags %d", flags);
> +
> +       if (device->flags == flags)
> +               return;
> +
> +       device->flags = flags;
> +
> +       g_dbus_emit_property_changed(dbus_conn, device->path,
> +                                       DEVICE_INTERFACE, "AdvertisingFlags");
> +}
> +
>  static gboolean start_discovery(gpointer user_data)
>  {
>         struct btd_device *device = user_data;
> diff --git a/src/device.h b/src/device.h
> index 387f598..93a159a 100644
> --- a/src/device.h
> +++ b/src/device.h
> @@ -97,6 +97,7 @@ void device_set_rssi_with_delta(struct btd_device *device, int8_t rssi,
>                                                         int8_t delta_threshold);
>  void device_set_rssi(struct btd_device *device, int8_t rssi);
>  void device_set_tx_power(struct btd_device *device, int8_t tx_power);
> +void device_set_flags(struct btd_device *device, uint8_t flags);
>  bool btd_device_is_connected(struct btd_device *dev);
>  uint8_t btd_device_get_bdaddr_type(struct btd_device *dev);
>  bool device_is_retrying(struct btd_device *device);
> --
> 2.8.0.rc3.226.g39d4020
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz

Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[Szymon Janc]

Hi,

On 19 October 2016 at 09:19, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Oct 18, 2016 at 10:10 PM,  <puthik@chromium.org> wrote:
>> From: Puthikorn Voravootivat <puthik@chromium.org>
>>
>> This exposed Advertising Flags to BlueZ Device API
>>
>> Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
>> ---
>>  doc/device-api.txt | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>> index f5cac49..1985698 100644
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -230,3 +230,7 @@ Properties  string Address [readonly]
>>
>>                         Indicate whether or not service discovery has been
>>                         resolved.
>> +
>> +               array{byte} AdvertisingFlags [readonly]
>> +
>> +                       The Advertising Data Flags of the remote device.
>
> It should probably be marked as experimental for now.

Hmm I wonder.. why not just expose full AD + SCAN_RSP this way?
Are we going to add prop for every data type?

-- 
pozdrawiam
Szymon K. Janc

Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[Luiz Augusto von Dentz]

Hi Szymon,

On Wed, Oct 19, 2016 at 7:15 PM, Szymon Janc <szymon.janc@codecoup.pl> wrote:
> Hi,
>
> On 19 October 2016 at 09:19, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Oct 18, 2016 at 10:10 PM,  <puthik@chromium.org> wrote:
>>> From: Puthikorn Voravootivat <puthik@chromium.org>
>>>
>>> This exposed Advertising Flags to BlueZ Device API
>>>
>>> Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
>>> ---
>>>  doc/device-api.txt | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>>> index f5cac49..1985698 100644
>>> --- a/doc/device-api.txt
>>> +++ b/doc/device-api.txt
>>> @@ -230,3 +230,7 @@ Properties  string Address [readonly]
>>>
>>>                         Indicate whether or not service discovery has been
>>>                         resolved.
>>> +
>>> +               array{byte} AdvertisingFlags [readonly]
>>> +
>>> +                       The Advertising Data Flags of the remote device.
>>
>> It should probably be marked as experimental for now.
>
> Hmm I wonder.. why not just expose full AD + SCAN_RSP this way?
> Are we going to add prop for every data type?

Then there is no reason to parse the AD, and even broken/unknown AD
should be send which sounds like a very dangerous think to do so Id
leave this for application that can deal with the management socket
but not over D-Bus.

-- 
Luiz Augusto von Dentz

Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[Johan Hedberg]

Hi Luiz,

On Wed, Oct 19, 2016, Luiz Augusto von Dentz wrote:
> > Hmm I wonder.. why not just expose full AD + SCAN_RSP this way?
> > Are we going to add prop for every data type?
> 
> Then there is no reason to parse the AD, and even broken/unknown AD
> should be send which sounds like a very dangerous think to do so Id
> leave this for application that can deal with the management socket
> but not over D-Bus.

I'm not so sure about this (having a "raw" AD/EIR API). We don't
necessarily need to expose the raw data as such, but it could be a
dictionary where the key is the data type and the value a byte array.
That'd at least prevent common pitfalls with broken parsing.

We could also consider making this a subscription based thing so that
it's not a broadcast signal but either a unicast signal or a method call
to whomever has requested to receive the information. Side note: I think
the approach the bus1 folks would like to take is to get rid of
broadcast signals completely and rely on a service-based subscription
mechanism.

Johan

Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags

[Puthikorn Voravootivat]

(Resend in Plain Text)

Hi Syzmon

> Are we going to add prop for every data type?
I only need the advertising flags. The others ones I need are already
properties in Bluez.Device

On Wed, Oct 19, 2016 at 10:15 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Luiz,
>
> On Wed, Oct 19, 2016, Luiz Augusto von Dentz wrote:
>> > Hmm I wonder.. why not just expose full AD + SCAN_RSP this way?
>> > Are we going to add prop for every data type?
>>
>> Then there is no reason to parse the AD, and even broken/unknown AD
>> should be send which sounds like a very dangerous think to do so Id
>> leave this for application that can deal with the management socket
>> but not over D-Bus.
>
> I'm not so sure about this (having a "raw" AD/EIR API). We don't
> necessarily need to expose the raw data as such, but it could be a
> dictionary where the key is the data type and the value a byte array.
> That'd at least prevent common pitfalls with broken parsing.
>
> We could also consider making this a subscription based thing so that
> it's not a broadcast signal but either a unicast signal or a method call
> to whomever has requested to receive the information. Side note: I think
> the approach the bus1 folks would like to take is to get rid of
> broadcast signals completely and rely on a service-based subscription
> mechanism.
>
> Johan