Hi Chen, On Tue, Nov 01, 2011, Ganir, Chen wrote: > 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. There must be something wrong with the spec or your understanding of it since this doesn't make any sense to me. The only thing that would make sense to me is if this 5 seconds only includes the inquiry phase but not the name resolving phase. Typically BR/EDR devices have their page timeout configured anywhere between 5 and 20 seconds. This means that for a single BR/EDR device that happens to be out of range when the time for name resolving comes, you could end up waiting quite long after the inquiry phase. Even for devices within range 1 second isn't an unusual time for name resolving, so you'd already go over 5 seconds with just 5 pre-2.1 devices around you. > 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? I don't know what you mean by "SCAN_COMPLETE" event, but this is what we can and should certainly do. However if there was a single device found for which we do not know the name, then the "pending" list will be empty and in the worst case we'll end up waiting for whatever we decide to use as a timeout. Note that this is not something that will always or even frequently happen. In most cases inquiry results come well before the inquiry complete and if the system isn't under really heavy load the kernel will receive its ack in much shorter time. Johan -- 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
