Hi Scott,
> This patch proposes an extension to the D-Bus Device API to allow
> an application access to the last EIR data received from a device
> in inquiry or advertising mode.
>
> Rationale is that increasing numbers of LE profiles are using custom
> fields in the advertising and scan response reports to carry important
> information. e.g. the Anki Drive peripherals include necessary
> information in the advertiesment that is not replicated in the GATT
> Service they export.
>
> It would be nice if it were possible to support these profiles at the
> application layer without extending BlueZ every time via a plugin.
>
> Since EIR has a variable-length type field, more complex parsing
> would require applications registering the types with BlueZ in advance
> putting a higher complexity burden on the daemon, including resolving
> conflicts where types overlap. Exposing the raw EIR data to the
> application allows them to deal with all such problems in whatever
> manner they require.
> ---
> doc/device-api.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index 577ee60..9620ec0 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -193,3 +193,8 @@ Properties string Address [readonly]
>
> Received Signal Strength Indicator of the remote
> device (inquiry or advertising).
> +
> + array{byte} EIR [readonly, optional]
> +
> + Last received EIR data from the remote device
> + during inquiry or advertising.
in general I have no objections in exposing the EIR and AD information. However I do not like to use EIR as property key. I know that on mgmt API we simply went with EIR_Data, but on the D-Bus API we most likely need to find a name that is a bit more generic and allows to represent EIR and AD information.
One important thing we have to consider are dual-mode devices that are found via LE and BR/EDR. With dual-mode topology from Bluetooth 4.1 this will become a real possibility and we want them to show under one object path. I think we need to brainstorm a little on how this can be done best.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
