2016-10-18 19:10:57

by Puthikorn Voravootivat

[permalink] [raw]
Subject: [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API

From: Puthikorn Voravootivat <[email protected]>

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



2016-10-20 01:54:14

by Puthikorn Voravootivat

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

(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 <[email protected]> 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

2016-10-19 17:15:58

by Johan Hedberg

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

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

2016-10-19 07:23:01

by Luiz Augusto von Dentz

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

Hi,

On Tue, Oct 18, 2016 at 10:11 PM, <[email protected]> wrote:
> From: Puthikorn Voravootivat <[email protected]>
>
> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
Luiz Augusto von Dentz

2016-10-19 16:21:53

by Luiz Augusto von Dentz

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

Hi Szymon,

On Wed, Oct 19, 2016 at 7:15 PM, Szymon Janc <[email protected]> wrote:
> Hi,
>
> On 19 October 2016 at 09:19, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi,
>>
>> On Tue, Oct 18, 2016 at 10:10 PM, <[email protected]> wrote:
>>> From: Puthikorn Voravootivat <[email protected]>
>>>
>>> This exposed Advertising Flags to BlueZ Device API
>>>
>>> Signed-off-by: Puthikorn Voravootivat <[email protected]>
>>> ---
>>> 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

2016-10-19 16:15:48

by Szymon Janc

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

Hi,

On 19 October 2016 at 09:19, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Tue, Oct 18, 2016 at 10:10 PM, <[email protected]> wrote:
>> From: Puthikorn Voravootivat <[email protected]>
>>
>> This exposed Advertising Flags to BlueZ Device API
>>
>> Signed-off-by: Puthikorn Voravootivat <[email protected]>
>> ---
>> 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

2016-10-19 07:19:39

by Luiz Augusto von Dentz

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

Hi,

On Tue, Oct 18, 2016 at 10:10 PM, <[email protected]> wrote:
> From: Puthikorn Voravootivat <[email protected]>
>
> This exposed Advertising Flags to BlueZ Device API
>
> Signed-off-by: Puthikorn Voravootivat <[email protected]>
> ---
> 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

2016-10-18 19:11:00

by Puthikorn Voravootivat

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

From: Puthikorn Voravootivat <[email protected]>

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 <[email protected]>
---
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


2016-10-18 19:10:59

by Puthikorn Voravootivat

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

From: Puthikorn Voravootivat <[email protected]>

This exposed Advertising Flags to BlueZ Device API

Signed-off-by: Puthikorn Voravootivat <[email protected]>
---
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


2016-10-18 19:10:58

by Puthikorn Voravootivat

[permalink] [raw]
Subject: [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API

From: Puthikorn Voravootivat <[email protected]>

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