Hi Szymon,
On Wed, Oct 19, 2016 at 7:15 PM, Szymon Janc <szymon.janc@xxxxxxxxxxx> wrote:
> Hi,
>
> On 19 October 2016 at 09:19, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> Hi,
>>
>> On Tue, Oct 18, 2016 at 10:10 PM, <puthik@xxxxxxxxxxxx> wrote:
>>> From: Puthikorn Voravootivat <puthik@xxxxxxxxxxxx>
>>>
>>> This exposed Advertising Flags to BlueZ Device API
>>>
>>> Signed-off-by: Puthikorn Voravootivat <puthik@xxxxxxxxxxxx>
>>> ---
>>> 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
--
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
