Issues with BlueZ v3.31 Object Path Naming

["David Stockwell" <dstockwell@frequency-one.com>]

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

I have not been chiming in for several weeks, because I have been busy hacking through code to figure out how bluez is supposed to work, how it actually works, and issues and incompatibilitites I am struggling with between bluez (DBus, v3.31) and the CSR BlueLab libraries (v4.0, compatible with BT2.1).; What fun.

In working with my test application, talking with bluez, I have run into the following and need clarification before proceeding:
  1.. What is the path name for the top level Manager interface?  Is it going to be "/org/bluez"? Or is it supposed to be "/"? 
    If you call the DefaultAdapter method with the "/org/bluez" path, it is resolved to call old_default_adapter in hcid/manager.c, returning a String representing the old Default Adapter path, or "/org/bluez/hci0"? 

    On the other hand, call the DefaultAdapter method with the "/" path, it is resolved to call default_adapter in hcid/manager.c, returning an Object (actually a string representing an object path), representing the NEW Default Adapter path: "/hci0".  However, when returning the Object, it also throws an error because, somehow, /hci0 was never registered.  (Unregistered object at path '/hci0'). Very bad result. 

    So, what should it be?  /org/bluez and /org/bluez/hci0?  Or / and /hci0? 

    And, while we are at it, should we clean up the documentation in docs/manager-api.txt and docs/adapter-api.txt?  Both refer to the "old" paths.  Let me know and I will be happy to "dive in". 

  2.. For what it is worth, the "new" and experimental Adapter methods ARE registered with path "/hci0", despite the apparent fact that no object '/hci0' is registered... 
  3.. I had been confused about opening an audio.Control device as opposed to (or in addition to, or in sequence with) a device under org.bluez.Adapter, using CreateDevice and CreatePairedDevice.  When I did get things to "work", sort of, CreateDevice would return a device path name like "/hci0/dev_xx_xx_xx_xx_xx_xx", but on return would fail with the same "Unregistered object at path" error as above. 
  4.. Along the lines of the last item, it does appear that one must pair, then one must create an audio "device" using the org.bluez.audio.Manager CreateDevice method (with path /org/bluez/audio).  Am I correct in this understanding? 
  5.. Yet another question: is the "/org/bluez/audio" path correct, or will it be changed in the future?  When I have used this method, it returns a device path of "/org/bluez/audio/device0".  It is interesting (and perhaps a bit strange) to use the device address, as opposed to the device path, to create this pseudo-device to provide the audio services (Device, Headset, Gateway, Sink, Source, Control).
I can quickly submit patches to unify the naming, etc., if you will tell me your current thinking and roadmap in this area.  However, I do not want to waste my time hacking if you are going in some other direction.

David Stockwell

[-- Attachment #2: Type: text/html, Size: 3641 bytes --]