Hi Alfonso, On Mon, Jan 8, 2018 at 7:32 AM, Alfonso Acosta <alfonso.acosta@xxxxxxxxx> wrote: > Hi Jamie, > >>>For the application’s purpose, it’s critical that the notification is recieved with the minimum latency. >> >> Is there any reason why you wish to have the button in a disconnected state when inactive over having it in a connected state but with a high connection interval and a large slave latency? A high slave latency means it can stay in sleep mode if there is nothing to report back to the central device for a specified number of packets so is perfect for battery powered devices. > > The only reason is: very high expectations of battery life. I recall > we played with the slave latency in the past, but we will reevaluate > and see if it's a feasible option. Thanks for the suggestion. > > Regardless, I am still curious to know if disconnecting and sending > the notification right away (as Luiz suggests) isn't racy with respect > to StartNotify(). The reason we maintain the attributes, if the device is not temporary, is exactly to avoid this race, but perhaps you a talking about temporary devices? We consider temporary devices those that have not been connected/paired or in case the devices use a random address that has not been resolved. Note that has been a lot of debate regarding this behavior of BlueZ, most stacks would remove any cache for devices which have not been paired but in BlueZ we choose to keep the cache to prevent this sort of race, which may be caused by intermittent connections. We do however only reload the device attributes once connecting, to avoid heavy io at startup, so if you are restarting bluetoothd it won't restore the objects right away. -- 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
