Hi Marcel & Alfonso, > I did start it with -E . In fact "gdbus introspect -r --system -o / > -d org.bluez" shows the GattManager1 interface, but no > dev_XX_XX_XX_XX_XX_XX/serviceXX(/charYYYY) object exposing > GattService1 or GattCharacteristic1, not even while connecting to > a bonded BLE device with GATT services. The experimental D-Bus API is not implemented, so yeah you won't see any of those objects. It is in the timeline to get that support built in the upcoming months but currently everyone who's using that API went and wrote their forked implementation of it. Some of the GATT server side support is there, so building and running with -E should expose a GattManager1, though I don't think that's fully implemented either. For client the quickest way for you might be to actually write a plugin (using the GAttrib code). I would just look at some of the profile code, like input/hog or heartrate and maybe add your implementation as a profile and expose a simple D-Bus API for it if necessary. Since you're not going to submit this upstream, this might be the quickest approach for the short term. Cheers, Arman -- 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
