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.
>
> Then we should find some alternative, perhaps only allow certain flags to
> be set this way or change the property to just Discoverable.
I would just add a single property Discoverable that maps to General Discoverable Mode. If you want to get extra credits, then adding DiscoverableTimeout (like we have in adapter-api.txt) would allow to switch it back from discoverable to connectable.
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
