Gents,
In the near-future 4.x, I understand that the org.bluez.audio.*
interfaces will be attached to the existing Device, such that the object
path (e.g.) /hci0/dev_* will have/export multiple DBus interfaces, not
only org.bluez.Device but also org.bluez.audio.Control (could be
multiple interfaces of the org.bluez.audio family). I also understand
that the org.bluez.audio.* interfaces will be set up based on the SDP
records in the host and remote when the connection/pairing is completed.
Is my understanding of this accurate?
Second question: org.bluez.Device has a number of properties (e.g.,
Connected) which are also valuable in the context of org.bluez.audio.*;
should we duplicate the appropriate properties (and code) into the
audio.* interface as well, or just require that anyone using wishing to
access these properties address org.bluez.Device? Similarly, when a
property changes, would we want to send the signal to a callback
listening to .Device and .audio.*, or only to .Device?
I think I have sensible answers (not to duplicate code/functionality),
but because I have not been to the meetings in Helsinki and elsewhere,
wanted to get your opinions and guidance.
FWIW, having resolved my other connection issues (to my satiafaction, at
least), I am now diving into audio.Control (/audio/control.c), with an
eye to providing a reasonable level of Metadata compliance/support.
David Stockwell
Frequency One
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
On Jul 21, 2008, at 20:40, David Stockwell wrote:
> In the near-future 4.x, I understand that the org.bluez.audio.*
> interfaces will be attached to the existing Device, such that the
> object
> path (e.g.) /hci0/dev_* will have/export multiple DBus interfaces, not
> only org.bluez.Device but also org.bluez.audio.Control (could be
> multiple interfaces of the org.bluez.audio family). I also understand
> that the org.bluez.audio.* interfaces will be set up based on the SDP
> records in the host and remote when the connection/pairing is
> completed.
>
> Is my understanding of this accurate?
Yes.
> Second question: org.bluez.Device has a number of properties (e.g.,
> Connected) which are also valuable in the context of
> org.bluez.audio.*;
> should we duplicate the appropriate properties (and code) into the
> audio.* interface as well, or just require that anyone using wishing
> to
> access these properties address org.bluez.Device? Similarly, when a
> property changes, would we want to send the signal to a callback
> listening to .Device and .audio.*, or only to .Device?
The org.bluez.Device property relates only to the low-level ACL status
and not to any higher level connections. The audio service would have
it's own signals it sends based on the state of its L2CAP or RFCOMM
sockets or even higher level protocol states on top of the sockets.
Johan
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel