public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Experimental Mode: org.bluez.Adapter Methods/Signals
Date: Sat, 29 Mar 2008 02:03:52 +0100	[thread overview]
Message-ID: <FC207646-9302-4A18-85DF-E054BE10A81D@holtmann.org> (raw)
In-Reply-To: <019401c8912b$e1876ff0$6701a8c0@freqonedev>

Hi David,

> In the adapter.c code (bluez-utils-3.29), there are a number of 4.x  
> methods and signals, which are enabled when hcid is run in  
> experimental mode (-x in startup).
>
> There are a whole lot of others that are labeled as "deprecated",  
> but which are currently available when hcid is in experimental mode,  
> as well as when it is not.  Are these in fact going to be dropped  
> when 4.x is released?

yes, with 4.0 all old ones will be dropped.

> On a similar topic:
>
> When the 4.x methods are registered, they register on bus  
> "org.bluez", with interface "org.bluez.Adapter", but unlike 3.x, the  
> path they use is not "/org/bluez/hci0" but just "/hci0" (for the  
> default case).  Is this intentional and the future direction of  
> bluez-dbus?

Yes. However use DefaultAdapter() or FindAdapter() to get the path.  
Hardcoded paths will fail in the future.

> I ask because when I tried calling DiscoverDevices, it would fail  
> when I called with path "/org/bluez/hci0", but would run when I  
> called it with path "/hci0".  But, the funny thing is that because  
> the RemoteDeviceFound signal is registered to both the old path and  
> the new path, the signals come back on "/org/bluez/hci0".

That is a bug in the 3.29 release and is already fixed in CVS.

> Interestingly enough, when I register callbacks for  
> DiscoveryStarted, RemoteDeviceFound, and DiscoveryCompleted against  
> proxies that reference both the old and new path, I find that  
> signals for DiscoveryStarted and DiscoveryCompleted come back  
> against both paths, but the actual RemoteDeviceFound (and  
> RemoteNameUpdated) comes back only against the 3.x path.

The RemoteDeviceFound will be a DeviceFound within 4.x and it will be  
a dictionary that can include the name if available.

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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

      reply	other threads:[~2008-03-29  1:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28 23:31 [Bluez-devel] Experimental Mode: org.bluez.Adapter Methods/Signals David Stockwell
2008-03-29  1:03 ` Marcel Holtmann [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=FC207646-9302-4A18-85DF-E054BE10A81D@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /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