Hi Luiz, On Mon, Mar 26, 2012 at 10:01 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > 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. True, but I'm testing all the possible user experiences and that's not an acceptable solution. The particular case I'm testing is that the user deleted the pairing on one end but not the other. I can't control what the software on my phone does; I'm only reporting how it interacts with BlueZ running on my device. It's true that the next time the connection occurs (provided we eventually figure out a SEP lock fix), everything will work just fine. I'm just trying to figure out what goes wrong the first time. So any pointers you have would be great. >>> 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. Well, this case helps out in a time where I didn't call Acquire (the phone initiated the connection). So it seems like there should be a check for pairing before initiating the timer. I'm not sure how that would work or what would be needed to make that foolproof. For my situation, a much higher timeout was sufficient (I'm not saying that it should be set to 60 in bluez.git -- just that for me it works). -- 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
