Hi Marcin,
On Wed, Apr 26, 2017 at 8:16 AM, Marcin Kraglak
<marcin.kraglak@xxxxxxxxx> wrote:
> Hi Luiz,
>
> On 25 April 2017 at 20:21, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote:
>> Hi Marcin,
>>
>> On Tue, Apr 25, 2017 at 2:56 PM, Marcin Kraglak
>> <marcin.kraglak@xxxxxxxxx> wrote:
>>> Clear services in range of Service Changed indication.
>>> From specification, Version 4.2 [Vol 3, Part G] 2.5.2 Attribute Caching:
>>> "The client, upon receiving a Handle Value Indication containing the range of
>>> affected Attribute Handles, shall consider the attribute cache invalid over
>>> the affected Attribute Handle range".
>>> ---
>>> src/shared/gatt-client.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
>>> index 0134721..7d23702 100644
>>> --- a/src/shared/gatt-client.c
>>> +++ b/src/shared/gatt-client.c
>>> @@ -1475,8 +1475,6 @@ static void service_changed_complete(struct discovery_op *op, bool success,
>>> util_debug(client->debug_callback, client->debug_data,
>>> "Failed to discover services within changed range - "
>>> "error: 0x%02x", att_ecode);
>>> -
>>> - gatt_db_clear_range(client->db, start_handle, end_handle);
>>> }
>>>
>>> /* Notify the upper layer of changed services */
>>> @@ -1514,7 +1512,8 @@ static void service_changed_failure(struct discovery_op *op)
>>> {
>>> struct bt_gatt_client *client = op->client;
>>>
>>> - gatt_db_clear_range(client->db, op->start, op->end);
>>> + util_debug(client->debug_callback, client->debug_data,
>>> + "Failed to process Service Changed");
>>> }
>>>
>>> static void process_service_changed(struct bt_gatt_client *client,
>>> @@ -1523,6 +1522,8 @@ static void process_service_changed(struct bt_gatt_client *client,
>>> {
>>> struct discovery_op *op;
>>>
>>> + gatt_db_clear_range(client->db, start_handle, end_handle);
>>> +
>>> op = discovery_op_create(client, start_handle, end_handle,
>>> service_changed_complete,
>>> service_changed_failure);
>>> --
>>> 2.4.3
>>
>> The code used to do exactly that, but it turn out it very inefficient
>> with devices that just loose the entire database when rebooted so we
>> started doing cache validation so we don't remove the services upfront
>> but check if the service range has changed so we prevent rediscovering
>> everything.
>>
> I see. Currently cached services, which were not found in new
> discovery after reconnect/service change (they were simply removed),
> are not unregistered. I guess it is not what we expect? If not I can
> fix it in another patch.
There is are calls to gatt_db_clear_range, so you are saying these do
not affect the D-Bus objects? If that is the case then yes we need to
fix it, but is it so that the services really changed because if they
don't there is no reason to remove the objects.
>> --
>> Luiz Augusto von Dentz
>
>
>
> --
> BR
> Marcin Kraglak
--
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
