Hi Arman, Jakub, On Tue, Jun 2, 2015 at 5:51 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Arman, > > On Tue, Jun 2, 2015 at 12:42 AM, Arman Uguray <armansito@xxxxxxxxxxxx> wrote: >>> Service changed, the lower is your requirement to reconnect the more >>> it will be required, but you got to pair to make it persistent across >>> reconnections but the first time you connect is always going to be >>> time consuming since you got to discover so it does not matter much if >>> the first time takes 9.7s to discover all services since the next time >>> it would not spend any time doing it again, that is the only reason >>> HoG can reconnect very fast. >>> >>> -- >>> 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 >> >> I'm late to the discussion, but wasn't this kind of functionality the >> whole point behind adding the org.bluez.GattProfile1 interface defined >> in doc/gatt-api.txt? Can't we do this through that? > > Yes, that was my suggestion to give a list of UUID of interested so > bt_gatt_client instance can skip discovery of characteristics and > descriptor not in the list, but it is not so simple when this is > dynamic as it is applications may come and go so we would have to > cache not only the database but also what was discovered which > complicate things. > > Btw, the spec says the following about the service changed: > > C1: Mandatory if service definitions on the server can be added, > changed or removed; > otherwise optional > > So the following code should be optimized to return without clearing > the database if service changed is not supported. > > if (device->le_state.bonded) > return; > > gatt_db_clear(device->db); > device->gatt_cache_used = false; > > Futhermore Im not sure we need to clear the database like that, we > could check if the service range match that probably means the service > has not changed since the last connection as is very unlikely that > service characteristics and descriptors would change even if the > service was removed and added again in the exact same place. Any chance that you guys give some feedback to the patch-set Ive sent yesterday? Im assuming it does take care of connecting to a single UUID since in most cases only Read by Group Type is necessary. -- 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
