On Thu, 2018-07-26 at 17:19 +0300, Luiz Augusto von Dentz wrote: > Hi, > > On Thu, Jul 26, 2018 at 3:43 PM, Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > On Wed, 2018-07-25 at 13:20 +0300, Luiz Augusto von Dentz wrote: > > > - property_set_mode_complete, data, > > > g_free) > 0) > > > + property_set_mode_complete, data, g_free) > > > > 0) > > > > White space change is probably not needed here. > > > > This patch and 4/4 don't work as expected though. I use this set of > > 2 > > commands to replicate what gnome-bluetooth did: > > > > dbus-send --system --dest=org.bluez /org/bluez/hci0 > > org.freedesktop.DBus.Properties.Set string:org.bluez.Adapter1 > > string:Discoverable variant:boolean:false ; dbus-send --system -- > > dest=org.bluez /org/bluez/hci0 org.freedesktop.DBus.Properties.Set > > string:org.bluez.Adapter1 string:DiscoverableTimeout > > variant:uint32:0 > > > > You can add a "print-reply" which will wait for the caller to > > return. > > In my case, without the --print-reply, property_set_mode will never > > be > > called. > > It looks like dbus-send cannot be used since it exits immediately, > anyway I tried by modifying bluetoothctl and it seems to be working > properly: > > https://gist.github.com/Vudentz/69737e4cc236f24d33404fffc5e51ff4 I think it's a bug in bluetoothd that it would drop property change requests when the caller goes away, but as you said, it works as expected when both properties are called from a single, long-running, client. Looks good -- 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
