Hi, On Wed, Dec 17, 2014, Biman Paul wrote: > If the device has initiated pairing and after that it tries to change > discovery mode, discovery mode change request is queued until the pairing > operation is completed(be it successful, failed, timeout). > > Steps to Reproduce: > 1. Initiate Pairing from Instrument Under Test > 2. Accept in Instrument under Test but do not accept in remote device > 3. Try to change the Visibility from off to on or on to off. > Visibility change does not happen until pairing operation is > completed(Pairing is accepted, rejected or timeout in remote). > > Please suggest the best way we can handle this. Can't you just enable discoverable mode *before* initiating pairing? :) On a more serious note, we do have the appropriate API for such situations: mgmt_reply (instead of mgmt_send) which skips the queue of mgmt commands. This is how canceling pairing works as well as responding to PIN or passkey requests (as otherwise these commands would only get sent when the pair command completes). So far we haven't extended the use of mgmt_reply anywhere else, but we could consider using it more extensively when pairing is active if we have good use cases for it. 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
