Subject: Re: Bug: no PropertiesChanged signal for
 org.bluez.Device1.AdvertisingData
To:     "Von Dentz, Luiz" <luiz.von.dentz@intel.com>
Cc:     linux-bluetooth@vger.kernel.org
References: <c23a8986-5654-275c-26a8-9f9a4bf5d005@invoxia.com>
 <CACumGOJrN1LFBb6uuH1T92eirzQyUMuai1qQ8SeipzJb=bvHUg@mail.gmail.com>
From:   Arnaud Mouiche <arnaud.mouiche@invoxia.com>
Message-ID: <5161f3b4-1c6b-6c53-4e6f-6f57ba12d3e5@invoxia.com>
Date:   Tue, 8 Jan 2019 20:00:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CACumGOJrN1LFBb6uuH1T92eirzQyUMuai1qQ8SeipzJb=bvHUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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
> <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.

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