Hi Luiz, > This enables the client to set its discoverable setting while > discovering which is very typical situation as usually the setings > application would allow incoming pairing request while scanning, so > this would reduce the number of calls setting Discoverable and > DiscoverableTimeout and restoring after done with discovery. > --- > doc/adapter-api.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt > index d14d0ca50..4791af2c7 100644 > --- a/doc/adapter-api.txt > +++ b/doc/adapter-api.txt > @@ -113,6 +113,12 @@ Methods void StartDiscovery() > generated for either ManufacturerData and > ServiceData everytime they are discovered. > > + bool Discoverable (Default: false) > + > + Make adapter discoverable while discovering, > + if the adapter is already discoverable this > + setting this filter won't do anything. > + > When discovery filter is set, Device objects will be > created as new devices with matching criteria are > discovered regardless of they are connectable or I am now regretting that we didn’t add a uint32 Flags parameter to Start Service Discovery mgmt command if this is something that is often done. Letting the kernel coordinate this properly for the lifetime of the discovery would be best. Otherwise things start to get racy eventually. Meaning that when implementing this in bluetoothd, we need to be careful to handle other mgmt commands correctly that might be issued from non-bluetoothd applications. Regards Marcel -- 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
