Marcel,
That "flame" was uncalled for. I have attached file bluez-utils-3.30/hcid/dbus-api.txt
The section describing the org.bluez.Adapter interface contains the following (emphasis added):
void DiscoverDevices()
This method starts the device discovery procedure. This
includes an inquiry procedure and remote device name
resolving.
On start up this process will generate a DiscoveryStarted
signal and then return ***RemoteDeviceFound*** and also
***RemoteNameUpdated*** signals. If the procedure has been
finished an DiscoveryCompleted signal will be sent.
Possible errors: org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.NoSuchAdapter
void DiscoverDevicesWithoutNameResolving()
This method starts the device discovery procedure. This
includes an inquiry and an optional remote device name
resolving. The remote names can be retrieved with
GetRemoteName and in the case a name doesn't exist it
will be queued for later resolving and GetRemoteName
will return an error.
While this procedure is running every found device
will be returned with ***RemoteDeviceFound***. While
DiscoverDevices() automatically resolves unknown
devices names and sends ***RemoteNameUpdated*** in this
case it will only happen if GetRemoteName has been
called and no previously stored name is available.
Possible errors: org.bluez.Error.NotReady
org.bluez.Error.Failed
org.bluez.Error.InProgress
org.bluez.Error.NoSuchAdapter
Note well: not "DeviceFound", but "RemoteDeviceFound".
The file I attached is the only dbus-api-txt found in the entire bluez-utils-3.30 tree. So, it appears the documentation is out of
date; after digging into the code at adapter.c, I found signals DeviceCreated, DeviceRemoved, and DeviceFound in the adapter_signals
table. I will implement "catches" for them, now, and expect that this problem will go away.
So, thanks in advance,
DS
----- Original Message -----
From: "Marcel Holtmann" <[email protected]>
To: "David Stockwell" <[email protected]>
Cc: "BlueZ development" <[email protected]>
Sent: Tuesday, April 08, 2008 1:56 PM
Subject: Re: [Bluez-devel] UPDATE: org.bluez.Adapter Methods/Signals
Hi David,
> To be clear, I have registered the RemoteDeviceFound and
> RemoteNameUpdated signals against both "/org/bluez/hci0" AND "/
> hci0" (both
> with "org.bluez.Adapter" interface). Signals for these signals
> always come back against "/org/bluez/hci0", and NOT against "/hci0"
> (path retrieved with dbus_g_proxy_get_path).
why don't you actually read the API documentation. Nobody said that
you can expect RemoteDeviceFound and RemoteNameUpdated on /hci0 and
you really can't. They are not sent. You get a DeviceFound signal.
Regards
Marcel
Hi David,
> That "flame" was uncalled for. I have attached file bluez-
> utils-3.30/hcid/dbus-api.txt
actually I mentioned before that you only will see DeviceFound on /
hci0 and if you look into the doc/ directory you see the documentation
for the new API. I mailed an update to the mailing list that mentioned
that from now on forward I am going to put new documentation there.
> The section describing the org.bluez.Adapter interface contains the
> following (emphasis added):
>
> void DiscoverDevices()
>
> This method starts the device discovery procedure. This
> includes an inquiry procedure and remote device name
> resolving.
>
> On start up this process will generate a DiscoveryStarted
> signal and then return ***RemoteDeviceFound*** and also
> ***RemoteNameUpdated*** signals. If the procedure has been
> finished an DiscoveryCompleted signal will be sent.
>
> Possible errors: org.bluez.Error.NotReady
> org.bluez.Error.Failed
> org.bluez.Error.InProgress
> org.bluez.Error.NoSuchAdapter
>
> void DiscoverDevicesWithoutNameResolving()
>
> This method starts the device discovery procedure. This
> includes an inquiry and an optional remote device name
> resolving. The remote names can be retrieved with
> GetRemoteName and in the case a name doesn't exist it
> will be queued for later resolving and GetRemoteName
> will return an error.
>
> While this procedure is running every found device
> will be returned with ***RemoteDeviceFound***. While
> DiscoverDevices() automatically resolves unknown
> devices names and sends ***RemoteNameUpdated*** in this
> case it will only happen if GetRemoteName has been
> called and no previously stored name is available.
>
> Possible errors: org.bluez.Error.NotReady
> org.bluez.Error.Failed
> org.bluez.Error.InProgress
> org.bluez.Error.NoSuchAdapter
>
> Note well: not "DeviceFound", but "RemoteDeviceFound".
Check doc/adapter-api.txt and you will see. I might mix up stuff from
time to time, but most times I mean exactly what I say. Also using
introspection utility like d-feet would have shown you this.
> The file I attached is the only dbus-api-txt found in the entire
> bluez-utils-3.30 tree. So, it appears the documentation is out of
> date; after digging into the code at adapter.c, I found signals
> DeviceCreated, DeviceRemoved, and DeviceFound in the adapter_signals
> table. I will implement "catches" for them, now, and expect that
> this problem will go away.
No. The documentation is all there. Depending on your entry point is
either / or /org/bluez you have to follow a different API.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel