Hi Johan, Marcel, On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg <[email protected]> wrote: > Hi Marcel, > > On Tue, Apr 23, 2013, Marcel Holtmann wrote: >> > I don't completely understand the rationale of wanting to make BlueZ's >> > clients so fragile. You could in theory get new services way after >> > pairing if this is configurable on the remote side. You could also get >> > the result of calling Device1.Connect() instead of Device1.Pair() in >> > BlueZ. >> > >> > On the other hand, we do delay the response to Device1.Pair() until SDP >> > is complete so delaying the Paired property would in a way be consistent >> > with that. I'll look into how simple this would be. We already track the >> > completion of SDP for each device internally with a svc_resolved boolean >> > so probably a new flag to indicate that "Paired" still needs to be >> > emitted should be all the extra context tracking we need. >> >> the pairing procedure is special and we should try to avoid any >> pointless round trips or wake ups for the clients here. We do know >> that we are running SDP after pairing anyway. So lets just wait for it >> to finish. Especially if we do that already anyway for Device1.Pair(). > > This ended up being quite simple to do, so I just pushed a mostly > untested patch for this to bluez.git. It'd be good if someone could > verify that it actually ends up helping the situation with oFono. >
How do remotely-initiated connections fit into this? We've seen devices that try to connect profiles immediately after pairing, I believe before the discovery is complete. Cheers, Mikel _______________________________________________ ofono mailing list [email protected] https://lists.ofono.org/mailman/listinfo/ofono
