* RE: MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress
@ 2014-12-17 8:55 Biman Paul
2014-12-17 9:19 ` Johan Hedberg
0 siblings, 1 reply; 2+ messages in thread
From: Biman Paul @ 2014-12-17 8:55 UTC (permalink / raw)
To: linux-bluetooth
Cc: 'JAGANATH KANAKKASSERY', 'CHETHAN T N',
'Seungyoun Ju', '시암'
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.
Thanks and Regards
Biman Paul
Samsung R&D Institute India - Bangalore
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress
2014-12-17 8:55 MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress Biman Paul
@ 2014-12-17 9:19 ` Johan Hedberg
0 siblings, 0 replies; 2+ messages in thread
From: Johan Hedberg @ 2014-12-17 9:19 UTC (permalink / raw)
To: Biman Paul
Cc: linux-bluetooth, 'JAGANATH KANAKKASSERY',
'CHETHAN T N', 'Seungyoun Ju',
'�þ�'
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-12-17 9:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-17 8:55 MGMT_OP_SET_DISCOVERABLE is queued for a long time if Pairing is in progress Biman Paul
2014-12-17 9:19 ` Johan Hedberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).