I would like to test BT 2.1 and SSP, and have installed the updated kernel with patches onto my system. To make the connection, I have to install or create an Agent that interacts with the BT daemon (currently, hcid), to deal with the pairing issues introduced by the SSSP (Secure "Supposedly Simple" Pairing). However, it also appears that the DBus interfaces are in flux.
So, what is the future of these; is it the org.bluez.Agent, as described in bluez-utils-3.34/doc/agent-api.txt? Or is it the old PasskeyAgent and AuthorizationAgent described in hcid/dbus-api.txt?
Also, the daemon/ directory used to contain sample code for a passkey agent and an authorization agent. If as I assume these need to move over to the .Agent interface, are there plans to provide a design example for these (or a combined agent daemon)?
Has the gnome agent been modified to the "experimental" interface?
When starting the sample passkey agent, it is possible to provide a path that the agent uses as its object path (in function register_agent, with the call to dbus_connection_register_object_path). I assume that this path is what we would pass to "Adapter.CreatePairedDevice" as the object path of the agent, with the capabilities string. Am I correct?
Any constraints on what this object path contains (for example: "/com/frequency-one")? I assume it must be unique and must not clash with the other paths under org.bluez.
Thanks in advance...
David Stockwell
Hi David,
> > Has the gnome agent been modified to the "experimental" interface?
>
> This one I'll have to let Marcel answer since he's responsible for it.
there is no support for the 4.x API in bluez-gnome.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
On Jun 27, 2008, at 23:07, David Stockwell wrote:
> So, what is the future of these; is it the org.bluez.Agent, as
> described in bluez-utils-3.34/doc/agent-api.txt? Or is it the old
> PasskeyAgent and AuthorizationAgent described in hcid/dbus-api.txt?
org.bluez.Agent is the "future" as you put it. It gets enabled through
the -x switch in 3.x versions. For 4.x the old PasskeyAgent and
AuthorizationAgent will go away.
> Also, the daemon/ directory used to contain sample code for a
> passkey agent and an authorization agent. If as I assume these need
> to move over to the .Agent interface, are there plans to provide a
> design example for these (or a combined agent daemon)?
There already is one. Take a look at hcid/simple-agent
> Has the gnome agent been modified to the "experimental" interface?
This one I'll have to let Marcel answer since he's responsible for it.
> When starting the sample passkey agent, it is possible to provide a
> path that the agent uses as its object path (in function
> register_agent, with the call to
> dbus_connection_register_object_path). I assume that this path is
> what we would pass to "Adapter.CreatePairedDevice" as the object
> path of the agent, with the capabilities string. Am I correct?
Yes. However in the CreatePairedDevice case the agent can't be
implemented by anyone else except the caller (since hcid identifies
the location of the agent by the unique name of the sender of
CreatePairedDevice) so typically it would be a different
implementation that the generic agent registered through RegisterAgent.
> Any constraints on what this object path contains (for example: "/
> com/frequency-one")? I assume it must be unique and must not clash
> with the other paths under org.bluez.
There are no constraints as long as it's a valid object path. The
agent's path resides in the agents object path hierarchy which is
totally independent from hcid's object path hierarchy (since they
reside withing two different processes).
Johan
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel