* [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API
@ 2016-10-18 19:10 puthik
2016-10-18 19:10 ` puthik
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: puthik @ 2016-10-18 19:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Puthikorn Voravootivat
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API 2016-10-18 19:10 [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API puthik @ 2016-10-18 19:10 ` puthik 2016-10-18 19:10 ` [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags puthik 2016-10-18 19:11 ` [PATCH v2 2/2] core: Add implementation of AdvertisingFlags puthik 2 siblings, 0 replies; 10+ messages in thread From: puthik @ 2016-10-18 19:10 UTC (permalink / raw) To: linux-bluetooth; +Cc: Puthikorn Voravootivat 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-18 19:10 [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API puthik 2016-10-18 19:10 ` puthik @ 2016-10-18 19:10 ` puthik 2016-10-19 7:19 ` Luiz Augusto von Dentz 2016-10-18 19:11 ` [PATCH v2 2/2] core: Add implementation of AdvertisingFlags puthik 2 siblings, 1 reply; 10+ messages in thread From: puthik @ 2016-10-18 19:10 UTC (permalink / raw) To: linux-bluetooth; +Cc: Puthikorn Voravootivat 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-18 19:10 ` [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags puthik @ 2016-10-19 7:19 ` Luiz Augusto von Dentz 2016-10-19 16:15 ` Szymon Janc 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2016-10-19 7:19 UTC (permalink / raw) To: puthik; +Cc: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-19 7:19 ` Luiz Augusto von Dentz @ 2016-10-19 16:15 ` Szymon Janc 2016-10-19 16:21 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Szymon Janc @ 2016-10-19 16:15 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: puthik, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-19 16:15 ` Szymon Janc @ 2016-10-19 16:21 ` Luiz Augusto von Dentz 2016-10-19 17:15 ` Johan Hedberg 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2016-10-19 16:21 UTC (permalink / raw) To: Szymon Janc; +Cc: puthik, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-19 16:21 ` Luiz Augusto von Dentz @ 2016-10-19 17:15 ` Johan Hedberg 2016-10-20 1:54 ` Puthikorn Voravootivat 0 siblings, 1 reply; 10+ messages in thread From: Johan Hedberg @ 2016-10-19 17:15 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Szymon Janc, puthik, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags 2016-10-19 17:15 ` Johan Hedberg @ 2016-10-20 1:54 ` Puthikorn Voravootivat 0 siblings, 0 replies; 10+ messages in thread From: Puthikorn Voravootivat @ 2016-10-20 1:54 UTC (permalink / raw) To: Luiz Augusto von Dentz, Szymon Janc, Puthikorn Voravootivat, linux-bluetooth (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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 2/2] core: Add implementation of AdvertisingFlags 2016-10-18 19:10 [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API puthik 2016-10-18 19:10 ` puthik 2016-10-18 19:10 ` [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags puthik @ 2016-10-18 19:11 ` puthik 2016-10-19 7:23 ` Luiz Augusto von Dentz 2 siblings, 1 reply; 10+ messages in thread From: puthik @ 2016-10-18 19:11 UTC (permalink / raw) To: linux-bluetooth; +Cc: Puthikorn Voravootivat 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/2] core: Add implementation of AdvertisingFlags 2016-10-18 19:11 ` [PATCH v2 2/2] core: Add implementation of AdvertisingFlags puthik @ 2016-10-19 7:23 ` Luiz Augusto von Dentz 0 siblings, 0 replies; 10+ messages in thread From: Luiz Augusto von Dentz @ 2016-10-19 7:23 UTC (permalink / raw) To: puthik; +Cc: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-10-20 1:54 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-18 19:10 [PATCH v2 0/2] Expose AdvertisingDataFlags in Device API puthik 2016-10-18 19:10 ` puthik 2016-10-18 19:10 ` [PATCH v2 1/2] doc/device-api: Add AdvertisingFlags puthik 2016-10-19 7:19 ` Luiz Augusto von Dentz 2016-10-19 16:15 ` Szymon Janc 2016-10-19 16:21 ` Luiz Augusto von Dentz 2016-10-19 17:15 ` Johan Hedberg 2016-10-20 1:54 ` Puthikorn Voravootivat 2016-10-18 19:11 ` [PATCH v2 2/2] core: Add implementation of AdvertisingFlags puthik 2016-10-19 7:23 ` Luiz Augusto von Dentz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.