On Tue, Jan 19, 2010 at 12:33 PM, Johan Hedberg <johan.hedberg(a)gmail.com> wrote:
On Tue, Jan 19, 2010, Luiz Augusto von Dentz wrote:
> Also the problem with this being in the device path is that ofono may
> not be registered as an agent on connect (both ways) which will cause
> the connection to drop and the round trips to resolve device path only
> makes it worse, if this happen to be on adapter path this would not be
> a problem since we know before hand who to call.
I don't think this is an issue in the case of a per-adapter handsfree
agent. Typically the agent would be registered upon the creation of the
device object. Yes, in theory a HFP connection establishment may occur
before ofono manages to register an agent for the device but the
connection doesn't need to be dropped because of it. Since it's the
HF-role device (i.e. us) that sends the initial AT command in HFP SLC
establishment bluetoothd could just sit quietly waiting until an agent
registers itself. When an agent finally gets registered bluetoothd would
(after replying to the registration method call) immediately call the
NewConnection() method for the agent.
Well it might work, but does it worth? Also I got the impression that
this is not optimal, specially if the we are simulating a combo device
hfp+a2dp this may delay the setup indefinitely until somebody register
an agent , so if I got it right our current code behind Audio.Connect
will not even attempt to connect the sink until headset state
transition from connecting.
Maybe and being paranoid, but I guess this might be troublesome for
mobile hardware where dbus is not that fast.
Luiz Augusto von Dentz
Engenheiro de Computação