Hi All, On Tue, Nov 1, 2011 at 4:11 PM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > Ilia, Johan, > >> > >> > Actually there are two more context switches involved which probably >> > introduce the most latency into the whole procedure: each time >> > bluetoothd gets a device_found event with confirm_name set to 1 it'll >> > need to access the file-system in /var/lib/bluetooth to check if the >> > name is stored there. >> >> Alright then, to be on the safe, let's do it 2 sec, my idea was >> to finish the whole process asap. But since io is involved, 2 sec >> seems to be a reasonable balance. >> > >> > Johan >> > > Please keep in mind that if you do it 2 seconds, that will cause a problem. In interleaved scanning, we need to scan for BR/EDR devices for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If we wait 2 seconds for timeout, this means 2 seconds in which we do nothing. This will mean that we need to scan for BR/EDR for 1 second, wait 2 seconds for ack, and then we will have about 2 more seconds for name requests for legacy devices. We need to think of a better solution here, which will coexist with interleaved device discovery. I guess we can tweak the page timeout as someone suggested in the meeting, anyway I have a feeling interleaved might change in the future, IMO the interval is big enough to annoy people. > What if we start name requests immediately after the inquiry is complete, according to what is already pending for name request (what the user has already confirmed for name request), and allow the user to confirm the name request for more devices up until we complete the name request process and return the SCAN_COMPLETE event ? The SCAN_COMPLETE event will be sent once the pending names list is clear, or any other limit we decide. You mean in parallel with LE scan? I don't think this is possible since name request involve paging so the baseband should be busy. -- 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
