Hi Luiz,
> This adds Flags which the application can use in case it want to set
> it own flags.
>
> Note: This would allow for example an application to advertise as
> discoverable even if the adapter is not discoverable which may be
> required by dual-mode as it may not require BR/EDR to be discoverable.
> ---
> doc/advertising-api.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/doc/advertising-api.txt b/doc/advertising-api.txt
> index eef98ad91..4e015f282 100644
> --- a/doc/advertising-api.txt
> +++ b/doc/advertising-api.txt
> @@ -78,6 +78,21 @@ Properties string Type
> <Transport Discovery> <Organization Flags...>
> 0x26 0x01 0x01...
>
> + array{byte} Flags [Experimental]
> +
> + Advertising Flags to include. When present this will
> + override existing flags such as Discoverable.
> +
> + Note: This property shall not be set when Type is set
> + to broadcast.
> +
> + Possible value:
> + bit 0 - LE Limited Discoverable Mode
> + bit 1 - LE General Discoverable Mode
> + bit 2 - BR/EDR Not Supported
> + bit 3 - Simultaneous LE and BR/EDR (Controller)
> + bit 4 - Simultaneous LE and BR/EDR (Host)
> +
I think this is the wrong approach. Exposing this low-level part is just giving an API to circumvent and violate the Bluetooth spec. You are inviting apps to create bad advertising data. So NAK.
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
