Hi Chen, On Wed, Mar 28, 2012, chen.ganir@xxxxxx wrote: > Add a callback mechanism for the btd_device, allowing other parts of > the bluez stack to receive notifications for device properties which > are changed. This mechanism is based on the D-BUS API for Device > PropertyChanged. > > Chen Ganir (4): > Add property changed callback > Centralize property changed events > Use macros instead of strings > Call registered callbacks > > src/device.c | 223 +++++++++++++++++++++++++++++++++++++++++++++++++--------- > src/device.h | 93 ++++++++++++++++++++++++ > 2 files changed, 281 insertions(+), 35 deletions(-) I don't think all this extra code is necessary for exposing a single device parameter like you described in the use case that you need this for. Instead we could consider introducing a callback specific to this very information. If some time in the future the amount of similar callbacks grows for various device parameters we could consider creating something more generic for them however even then that wouldn't be based on top of D-Bus properties (the inverse might be possible though: handling the D-Bus property signals using this generic framework). Johan -- 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
