Hi Luiz, 2015-07-22 21:50 GMT+09:00, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>: > Hi Dohyun, > > On Sun, Jul 19, 2015 at 6:31 PM, Dohyun Pyun <re20sfree@xxxxxxxxx> wrote: >> From: DoHyun Pyun <dh79.pyun@xxxxxxxxxxx> >> >> Since BlueZ has ObjectManager interface, ChannelConnected and >> ChannelDeleted >> Signals of HealthDevice interface was not available. ObjectManager reports >> the >> HealthChannel D-Bus interface when g_dbus_emit_signal function is called, >> and generates "InterfaceAdded" signal. But ChannelConnected and >> ChannelDeleted >> Siganls was not generated. If health-api document contains these signals, >> application or service using Bluez Dbus API will get the unexpected >> result. >> >> If we just remove g_dbus_emit_signal for ChannelConnected and >> ChannelDeleted, >> InterfaceAdded signal will not sent. Because InterfaceAdded signal is >> pending >> before sending a dbus signal. These patches include new property in >> HealthChannel >> interfacem, and this PropertiesChanged signal can be used to replace the >> previous >> ChannelConnected and ChannelDeleted signals. > > Seems like a good idea, but from the logs it looks like the channel > lifetime is tied with the connection in that case > InterfacesAdded/InterfacesRemoved can be used directly instead of > having another property or Im missing something? > When I re-test the possible senarios without "PropertiesChanged" Signal after removing the ChannelConnected and ChannelRemoved signals. It looks no problem. As you said, we can use InterfacesAdded / InterfacesRemoved event directly. After verifying the operations, I will re-make the patchsets - only include remove the previous signals (ChannelConnected/ ChannelRemoved) Thanks, Pyun -- 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
