From: Johan Hedberg <johan.hedberg@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH] hfp_hf_bluez5: Fix re-registering a modem for a device
Date: Thu, 25 Apr 2013 12:37:53 +0300 [thread overview]
Message-ID: <20130425093753.GA8845@x220.ger.corp.intel.com> (raw)
In-Reply-To: <CANT-zCWa2CZa8YC7WXcFymBCiKnYmgKyDH3aceXpViPdo8hhFQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
Hi Mikel,
On Thu, Apr 25, 2013, Mikel Astiz wrote:
> On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg <johan.hedberg@gmail.com> 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.
Both the NewConnection() (including the authorization of the incoming
L2CAP/RFCOMM connect request) and the Paired property would even then be
delayed until our side has completed its full service discovery.
Johan
next prev parent reply other threads:[~2013-04-25 9:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-22 22:53 [PATCH] hfp_hf_bluez5: Fix re-registering a modem for a device Vinicius Costa Gomes
2013-04-23 9:06 ` Denis Kenzior
2013-04-23 15:23 ` Johan Hedberg
2013-04-23 15:34 ` Marcel Holtmann
2013-04-23 16:15 ` Johan Hedberg
2013-04-23 16:27 ` Marcel Holtmann
2013-04-23 17:28 ` Johan Hedberg
2013-04-23 18:39 ` Vinicius Costa Gomes
2013-04-25 8:51 ` Mikel Astiz
2013-04-25 9:37 ` Johan Hedberg [this message]
2013-04-25 8:27 ` Denis Kenzior
2013-04-25 17:47 ` Vinicius Costa Gomes
2013-04-25 22:48 ` Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130425093753.GA8845@x220.ger.corp.intel.com \
--to=johan.hedberg@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox