From: "David Stockwell" <dstockwell@frequency-one.com>
To: "Marcel Holtmann" <marcel@holtmann.org>
Cc: "BlueZ development" <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] UPDATE: org.bluez.Adapter Methods/Signals
Date: Tue, 8 Apr 2008 19:08:54 -0500 [thread overview]
Message-ID: <012d01c899d5$e7236740$6701a8c0@freqonedev> (raw)
In-Reply-To: 1D6A3083-03A3-4698-A040-DD010CC4EBAD@holtmann.org
Thanks. After digging into ~/bluez-utils-3.30/doc/... the situation became significantly more clear. I see the names of the
xxx-api.txt are also changed, which is why I did not find them before...sigh.
All the best,
DS
----- Original Message -----
From: "Marcel Holtmann" <marcel@holtmann.org>
To: "David Stockwell" <dstockwell@frequency-one.com>
Cc: "BlueZ development" <bluez-devel@lists.sourceforge.net>
Sent: Tuesday, April 08, 2008 6:36 PM
Subject: Re: [Bluez-devel] UPDATE: org.bluez.Adapter Methods/Signals
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
prev parent reply other threads:[~2008-04-09 0:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-07 22:45 [Bluez-devel] UPDATE: org.bluez.Adapter Methods/Signals David Stockwell
2008-04-07 22:58 ` Marcel Holtmann
2008-04-08 17:54 ` David Stockwell
2008-04-08 18:56 ` Marcel Holtmann
2008-04-08 23:07 ` David Stockwell
2008-04-08 23:36 ` Marcel Holtmann
2008-04-09 0:08 ` David Stockwell [this message]
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='012d01c899d5$e7236740$6701a8c0@freqonedev' \
--to=dstockwell@frequency-one.com \
--cc=bluez-devel@lists.sourceforge.net \
--cc=marcel@holtmann.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