Hi Mike, On Fri, Mar 23, 2012 at 12:30 PM, Mike <puffy.taco@xxxxxxxxx> wrote: > It does appear to trigger based on the signalling channel, however it > appears that the connection process continues on regardless. I pasted > below a log, everything in the log occurs while my phone is still > asking me if I want to pair with the BlueZ device. We don't get > beyond the OPEN_CMD into an actual OPEN state until the pairing > process completes. Why don't you pair it before hand, actually this should happen only once in the first time you pair and then it should be stored persistently so the next time you wont see this problem. >> 60 seconds is way too long, it should be at least smaller than D-Bus >> default timeout which is 25 sec. > > What exactly is this timeout waiting for? I haven't figured that out > yet. I assume it's waiting on something from my phone (the a2dp > source) and not D-Bus? The client is would be waiting the reply of Acquire, so if you setup something over D-Bus timeout there is a chance the device respond correctly but the client will ignored because the method call already timed out. -- 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
