Hello Luiz,
I was playing with latest sources (git) and experimental features
enabled in order to:
- perform a BLE scan
- find AdvertisingData (in particularly the BT_AD_INDOOR_POSITIONING (0x25))
I found that:
- once scanning is done org.bluez.Device1.AdvertisingData is correctly
set to the expected value (the one advertised)
- yet, there was no PropertiesChanged signal corresponding to this
AdvertisingData property update (despite I received PropertiesChanged
for RSSI)
Indeed src/device.c:: add_data() performs a particular filtering to only
signal EIR_TRANSPORT_DISCOVERY data.
> static void add_data(void *data, void *user_data)
> {
> struct eir_ad *ad = data;
> struct btd_device *dev = user_data;
>
> if (!bt_ad_add_data(dev->ad, ad->type, ad->data, ad->len))
> return;
>
> if (ad->type == EIR_TRANSPORT_DISCOVERY)
> g_dbus_emit_property_changed(dbus_conn, dev->path,
> DEVICE_INTERFACE,
> "AdvertisingData");
> }
Is there a particular reason for this behavior ?
Regards,
Arnaud
Hi Arnaud,
On Tue, Jan 8, 2019 at 1:03 PM Arnaud Mouiche
<[email protected]> wrote:
>
> Hello Luiz,
>
> I was playing with latest sources (git) and experimental features
> enabled in order to:
> - perform a BLE scan
> - find AdvertisingData (in particularly the BT_AD_INDOOR_POSITIONING (0x25))
>
> I found that:
> - once scanning is done org.bluez.Device1.AdvertisingData is correctly
> set to the expected value (the one advertised)
> - yet, there was no PropertiesChanged signal corresponding to this
> AdvertisingData property update (despite I received PropertiesChanged
> for RSSI)
Is the Data changing? If you want to get informed of each
advertisement regardless if it has changed you should set
DuplicateData filter:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n107
If that doesn't work then perhaps we have a bug somewhere.
>
> Indeed src/device.c:: add_data() performs a particular filtering to only
> signal EIR_TRANSPORT_DISCOVERY data.
>
> > static void add_data(void *data, void *user_data)
> > {
> > struct eir_ad *ad = data;
> > struct btd_device *dev = user_data;
> >
> > if (!bt_ad_add_data(dev->ad, ad->type, ad->data, ad->len))
> > return;
> >
> > if (ad->type == EIR_TRANSPORT_DISCOVERY)
> > g_dbus_emit_property_changed(dbus_conn, dev->path,
> > DEVICE_INTERFACE,
> > "AdvertisingData");
> > }
>
> Is there a particular reason for this behavior ?
If I recall this is not to spam the bus if we are not actively discovery.
> Regards,
> Arnaud
>
Hello Luiz,
On 08/01/2019 17:12, Von Dentz, Luiz wrote:
> Hi Arnaud,
>
> On Tue, Jan 8, 2019 at 1:03 PM Arnaud Mouiche
> <[email protected]> wrote:
>> Hello Luiz,
>>
>> I was playing with latest sources (git) and experimental features
>> enabled in order to:
>> - perform a BLE scan
>> - find AdvertisingData (in particularly the BT_AD_INDOOR_POSITIONING (0x25))
>>
>> I found that:
>> - once scanning is done org.bluez.Device1.AdvertisingData is correctly
>> set to the expected value (the one advertised)
>> - yet, there was no PropertiesChanged signal corresponding to this
>> AdvertisingData property update (despite I received PropertiesChanged
>> for RSSI)
> Is the Data changing? If you want to get informed of each
> advertisement regardless if it has changed you should set
> DuplicateData filter:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n107
>
> If that doesn't work then perhaps we have a bug somewhere.
Yes "duplicate" is true
>
>> Indeed src/device.c:: add_data() performs a particular filtering to only
>> signal EIR_TRANSPORT_DISCOVERY data.
>>
>>> static void add_data(void *data, void *user_data)
>>> {
>>> struct eir_ad *ad = data;
>>> struct btd_device *dev = user_data;
>>>
>>> if (!bt_ad_add_data(dev->ad, ad->type, ad->data, ad->len))
>>> return;
>>>
>>> if (ad->type == EIR_TRANSPORT_DISCOVERY)
>>> g_dbus_emit_property_changed(dbus_conn, dev->path,
>>> DEVICE_INTERFACE,
>>> "AdvertisingData");
>>> }
>> Is there a particular reason for this behavior ?
> If I recall this is not to spam the bus if we are not actively discovery.
I did some tracing and the "ad->type == EIR_TRANSPORT_DISCOVERY" test is
the one filtering the property change signal.
Should we set a white/black list for this kind of filtering ? or
something else... ?
Regards,
Arnaud