Re: Bug: no PropertiesChanged signal for org.bluez.Device1.AdvertisingData

["Von Dentz, Luiz" <luiz.von.dentz@intel.com>]

Hi Arnaud,

On Tue, Jan 8, 2019 at 1:03 PM Arnaud Mouiche
<arnaud.mouiche@invoxia.com> 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
>