Hi On 01/11/2016 12:22 AM, Luiz Augusto von Dentz wrote: > Hi, > > On Mon, Nov 30, 2015 at 6:12 AM, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi, >> >> On Mon, Nov 30, 2015 at 9:59 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: >>> Hi, >>> >>> On Mon, Nov 30, 2015, Jonas Holmberg wrote: >>>> On 11/30/2015 08:16 AM, Andrejs Hanins wrote: >>>>> Hi, >>>>> >>>>> On 11/29/2015 04:04 AM, Ryan Kuester wrote: >>>>>> Hello everyone, >>>>>> >>>>>> When registering a GATT service via the D-Bus API, bluez-5.36 >>>>>> seems to expect the objects returned by the service's >>>>>> GetManagedObjects method to include the service object itself, >>>>>> the root of the managed object tree. Indeed, the included >>>>>> test/example-gatt-server behaves this way[1]. >>>>>> >>>>>> However, the D-Bus Specification seems to say an ObjectManager >>>>>> should return the objects *under* the ObjectManager, i.e., only >>>>>> the service's children---characteristics and descriptors. This >>>>>> reading of the specification is in agreement with the >>>>>> ObjectManager implementations in GDBus and Python's txdbus (I >>>>>> didn't check other implementations). >>>>>> >>>>>> bluez's disagreement with the standard causes pain when trying to >>>>>> use the ObjectManager implementations in the libraries, because >>>>>> they don't return the ObjectManager itself, the service object, >>>>>> as bluez expects. E.g., in txdbus, it's impossible to implement >>>>>> the ObjectManager interface in application code (to get the >>>>>> non-standard behavior) without patching the library. >>>>>> >>>>>> Does the expectation that the service object appear in the >>>>>> GetManagedObjects result look like a disagreement with the D-Bus >>>>>> standard to anyone else? >>>>> The same to me. I'm using Glib/Glibmm to export GATT services and >>>>> Glib D-Bus code asserts in debug mode when object path matches >>>>> with object manager path. I'm currently blindly ignoring this, cause >>>>> it doesn't seems to cause any functionality problems in release code. >>>> I was also bitten by that assert. I assumed it was a bug so I wrote a >>>> bug report about it: https://bugzilla.gnome.org/show_bug.cgi?id=758393 >>>> But after this discussion I'm not sure if it is a bug. >>> It appears to be a bug in the BlueZ implementation and D-Bus API. It >>> was already discussed many months ago, but no one seems to have >>> submitted patches to fix it: >>> >>> http://comments.gmane.org/gmane.linux.bluez.kernel/63291 >>> https://bugs.freedesktop.org/show_bug.cgi?id=91283 >>> https://github.com/systemd/systemd/issues/525#issuecomment-126746787 >> Yep, I guess we lost track of it in the mailing list but we should >> definitely fix it. One idea that comes to me is to change the >> RegisterService to RegisterApplication and then have all its services >> registered at once: >> >> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt >> index d832c73..f1940ba 100644 >> --- a/doc/gatt-api.txt >> +++ b/doc/gatt-api.txt >> @@ -270,9 +270,9 @@ must be available on the root service path. An >> example application hierarchy >> containing two separate GATT services may look like this: >> >> -> /com/example >> + | - org.freedesktop.DBus.ObjectManager >> | >> -> /com/example/service0 >> - | | - org.freedesktop.DBus.ObjectManager >> | | - org.freedesktop.DBus.Properties >> | | - org.bluez.GattService1 >> | | >> @@ -289,7 +289,6 @@ containing two separate GATT services may look like this: >> | - org.bluez.GattDescriptor1 >> | >> -> /com/example/service1 >> - | - org.freedesktop.DBus.ObjectManager >> | - org.freedesktop.DBus.Properties >> | - org.bluez.GattService1 >> | >> @@ -309,21 +308,21 @@ Service org.bluez >> Interface org.bluez.GattManager1 [Experimental] >> Object path [variable prefix]/{hci0,hci1,...} >> >> -Methods void RegisterService(object service, dict options) >> +Methods void RegisterApplication(object application, >> dict options) >> >> - Registers a local GATT service hierarchy as described >> + Registers a local GATT services hierarchy as described >> above. >> >> - "service" object path together with the D-Bus system >> - bus connection ID define the identification of the >> - application registering a GATT based service. >> + The application object path together with the D-Bus >> + system bus connection ID define the identification of >> + the application registering a GATT based service. >> >> Possible errors: org.bluez.Error.InvalidArguments >> org.bluez.Error.AlreadyExists >> >> - void UnregisterService(object service) >> + void UnregisterApplication(object application) >> >> - This unregisters the service that has been >> + This unregisters the services that has been >> previously registered. The object path parameter >> must match the same value that has been used >> on registration. > Any comments to the patches Ive sent upstream, Id like to push them > which will result in breaking the current (experimental) API so I hope > it doesn't take anyone by surprise. > I've tested the patches and they work good for me, I can now register GATT services (and they work well) one level down the D-Bus Object Manager, Glib doesn't assert anymore. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
