The D-Bus end-points for those 2 properties are:
property_set_discoverable and property_set_discoverable_timeout
in src/adapter.c
bluetoothd, to change those properties, calls out asynchronously to the kernel:
property_set_mode -> async stuff -> property_set_mode_complete -> new_settings_callback() sets adapter->current_settings
And to those used to async programming, the problem should be obvious. In
property_set_discoverable_timeout():
if (adapter->current_settings & MGMT_SETTING_DISCOVERABLE) set_discoverable(adapter, 0x01, adapter->discoverable_timeout);
So if a discoverable setting is pending, adapter->current_settings isn't set to the new value, and discoverable is *reset* to on.
This is a definite bug in bluez, though work-aroundable in gnome-bluetooth.
The D-Bus end-points for those 2 properties are: set_discoverabl e and property_ set_discoverabl e_timeout
property_
in src/adapter.c
bluetoothd, to change those properties, calls out asynchronously to the kernel: set_mode_ complete -> new_settings_ callback( ) sets adapter- >current_ settings
property_set_mode -> async stuff -> property_
And to those used to async programming, the problem should be obvious. In set_discoverabl e_timeout( ): >current_ settings & MGMT_SETTING_ DISCOVERABLE)
set_discovera ble(adapter, 0x01, adapter- >discoverable_ timeout) ;
property_
if (adapter-
So if a discoverable setting is pending, adapter- >current_ settings isn't set to the new value, and discoverable is *reset* to on.
This is a definite bug in bluez, though work-aroundable in gnome-bluetooth.