Add command to management interface for enabling/disabling the
fast connectable mode.
Signed-off-by: Antti Julku <[email protected]>
---
include/net/bluetooth/hci.h | 10 +++++++
include/net/bluetooth/mgmt.h | 5 +++
net/bluetooth/mgmt.c | 60 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 65345cd..d7b9600 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
bdaddr_t bdaddr;
} __packed;
+#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY 0x0c1c
+struct hci_cp_write_page_scan_activity {
+ __le16 interval;
+ __le16 window;
+} __packed;
+
+#define HCI_OP_WRITE_PAGE_SCAN_TYPE 0x0c47
+ #define PAGE_SCAN_TYPE_STANDARD 0x00
+ #define PAGE_SCAN_TYPE_INTERLACED 0x01
+
#define HCI_OP_LE_SET_EVENT_MASK 0x2001
struct hci_cp_le_set_event_mask {
__u8 mask[8];
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 45bea25..7196d04 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
bdaddr_t bdaddr;
} __packed;
+#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
+struct mgmt_cp_set_fast_connectable {
+ __u8 enable;
+} __packed;
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
__le16 opcode;
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 64c0418..a472a60 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1730,6 +1730,62 @@ static int unblock_device(struct sock *sk, u16 index, unsigned char *data,
return err;
}
+static int set_fast_connectable(struct sock *sk, u16 index,
+ unsigned char *data, u16 len)
+{
+ struct hci_dev *hdev;
+ struct mgmt_cp_set_fast_connectable *cp = (void *) data;
+ struct hci_cp_write_page_scan_activity acp;
+ u8 type;
+ int err;
+
+ BT_DBG("hci%u", index);
+
+ if (len != sizeof(*cp))
+ return cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
+ EINVAL);
+
+ hdev = hci_dev_get(index);
+ if (!hdev)
+ return cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
+ ENODEV);
+
+ hci_dev_lock(hdev);
+
+ if (cp->enable) {
+ type = PAGE_SCAN_TYPE_INTERLACED;
+ acp.interval = 0x0024; /* 22.5 msec page scan interval */
+ } else {
+ type = PAGE_SCAN_TYPE_STANDARD; /* default */
+ acp.interval = 0x0800; /* default 1.28 sec page scan */
+ }
+
+ acp.window = 0x0012; /* default 11.25 msec page scan window */
+
+ err = hci_send_cmd(hdev, HCI_OP_WRITE_PAGE_SCAN_ACTIVITY,
+ sizeof(acp), &acp);
+ if (err < 0) {
+ err = cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
+ -err);
+ goto done;
+ }
+
+ err = hci_send_cmd(hdev, HCI_OP_WRITE_PAGE_SCAN_TYPE, 1, &type);
+ if (err < 0) {
+ err = cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
+ -err);
+ goto done;
+ }
+
+ err = cmd_complete(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
+ NULL, 0);
+done:
+ hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
+
+ return err;
+}
+
int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
{
unsigned char *buf;
@@ -1850,6 +1906,10 @@ int mgmt_control(struct sock *sk, struct msghdr *msg, size_t msglen)
case MGMT_OP_UNBLOCK_DEVICE:
err = unblock_device(sk, index, buf + sizeof(*hdr), len);
break;
+ case MGMT_OP_SET_FAST_CONNECTABLE:
+ err = set_fast_connectable(sk, index, buf + sizeof(*hdr),
+ len);
+ break;
default:
BT_DBG("Unknown op %u", opcode);
err = cmd_status(sk, index, opcode, 0x01);
--
1.7.2.5
Hi Antti,
> Add command to management interface for enabling/disabling the
> fast connectable mode.
>
> Signed-off-by: Antti Julku <[email protected]>
> ---
> include/net/bluetooth/hci.h | 10 +++++++
> include/net/bluetooth/mgmt.h | 5 +++
> net/bluetooth/mgmt.c | 60 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 75 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 65345cd..d7b9600 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
> bdaddr_t bdaddr;
> } __packed;
>
> +#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY 0x0c1c
> +struct hci_cp_write_page_scan_activity {
> + __le16 interval;
> + __le16 window;
> +} __packed;
> +
> +#define HCI_OP_WRITE_PAGE_SCAN_TYPE 0x0c47
> + #define PAGE_SCAN_TYPE_STANDARD 0x00
> + #define PAGE_SCAN_TYPE_INTERLACED 0x01
> +
> #define HCI_OP_LE_SET_EVENT_MASK 0x2001
> struct hci_cp_le_set_event_mask {
> __u8 mask[8];
> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
> index 45bea25..7196d04 100644
> --- a/include/net/bluetooth/mgmt.h
> +++ b/include/net/bluetooth/mgmt.h
> @@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
> bdaddr_t bdaddr;
> } __packed;
>
> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
> +struct mgmt_cp_set_fast_connectable {
> + __u8 enable;
> +} __packed;
> +
so I am not 100% sure that doing it this way is the best way.
What is the down side of just enabling interlaced page scan all the
time? And then maybe allow tuning of the timeout via debugfs for testing
purposes.
If we really wanna differentiate between connectable and fast
connectable, then we need to fix up also the controller information to
export this kind of detail. That will get pretty messy right now. So I
would really just prefer to go with interlaced page scan by default and
see what downside this gives us.
Regards
Marcel
Hi Antti,
* Antti Julku <[email protected]> [2011-06-17 12:43:48 +0300]:
> Add command to management interface for enabling/disabling the
> fast connectable mode.
>
> Signed-off-by: Antti Julku <[email protected]>
> ---
> include/net/bluetooth/hci.h | 10 +++++++
> include/net/bluetooth/mgmt.h | 5 +++
> net/bluetooth/mgmt.c | 62 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 77 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 65345cd..d7b9600 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
> bdaddr_t bdaddr;
> } __packed;
>
> +#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY 0x0c1c
> +struct hci_cp_write_page_scan_activity {
> + __le16 interval;
> + __le16 window;
> +} __packed;
> +
> +#define HCI_OP_WRITE_PAGE_SCAN_TYPE 0x0c47
> + #define PAGE_SCAN_TYPE_STANDARD 0x00
> + #define PAGE_SCAN_TYPE_INTERLACED 0x01
> +
> #define HCI_OP_LE_SET_EVENT_MASK 0x2001
> struct hci_cp_le_set_event_mask {
> __u8 mask[8];
> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
> index 45bea25..7196d04 100644
> --- a/include/net/bluetooth/mgmt.h
> +++ b/include/net/bluetooth/mgmt.h
> @@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
> bdaddr_t bdaddr;
> } __packed;
>
> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
> +struct mgmt_cp_set_fast_connectable {
> + __u8 enable;
> +} __packed;
> +
> #define MGMT_EV_CMD_COMPLETE 0x0001
> struct mgmt_ev_cmd_complete {
> __le16 opcode;
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 64c0418..b4bed16 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -1730,6 +1730,64 @@ static int unblock_device(struct sock *sk, u16 index, unsigned char *data,
> return err;
> }
>
> +static int set_fast_connectable(struct sock *sk, u16 index,
> + unsigned char *data, u16 len)
> +{
> + struct hci_dev *hdev;
> + struct mgmt_cp_set_fast_connectable *cp;
set cp = data here.
> + struct hci_cp_write_page_scan_activity acp;
> + u8 type;
> + int err;
> +
> + BT_DBG("hci%u", index);
> +
> + cp = (void *) data;
> +
> + if (len != sizeof(*cp))
> + return cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
> + EINVAL);
> +
> + hdev = hci_dev_get(index);
> + if (!hdev)
> + return cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
> + ENODEV);
> +
> + hci_dev_lock(hdev);
> +
> + if (cp->enable) {
> + type = PAGE_SCAN_TYPE_INTERLACED;
> + acp.interval = 0x0024; /* 22.5 msec page scan interval */
> + } else {
> + type = PAGE_SCAN_TYPE_STANDARD; /* default */
> + acp.interval = 0x0800; /* default 1.28 sec page scan */
> + }
> +
> + acp.window = 0x0012; /* default 11.25 msec page scan window */
> +
> + err = hci_send_cmd(hdev, HCI_OP_WRITE_PAGE_SCAN_ACTIVITY,
> + sizeof(acp), &acp);
> + if (err < 0) {
> + err = cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
> + -err);
> + goto failed;
> + }
> +
> + err = hci_send_cmd(hdev, HCI_OP_WRITE_PAGE_SCAN_TYPE, 1, &type);
> + if (err < 0) {
> + err = cmd_status(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
> + -err);
> + goto failed;
> + }
> +
> + err = cmd_complete(sk, index, MGMT_OP_SET_FAST_CONNECTABLE,
> + NULL, 0);
> +failed:
Call this "done" as the normal code path ends here as well.
Gustavo
Hi Marcel,
On Mon, Jul 25, 2011 at 4:38 PM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Dmitriy,
>
>> >> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
>> >> +struct mgmt_cp_set_fast_connectable {
>> >> + =A0 =A0 __u8 enable;
>> >> +} __packed;
>> >> +
>> >
>> > so I am not 100% sure that doing it this way is the best way.
>> >
>> > What is the down side of just enabling interlaced page scan all the
>> > time? And then maybe allow tuning of the timeout via debugfs for testi=
ng
>> > purposes.
>>
>> This mode changes two parameters: page scan type and page scan
>> interval. There two downsides to have those changed all the time:
>> 1) power consumption
>> 2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
>>
>> In this configuration page scanning happening during all dedicated
>> slots and much more frequently. This is why probably it is not very
>> good idea to have it enabled all the time, but only during short time
>> interval when there are benefits out of such changes.
>
> so the expectation is that bluetoothd or some sort of its plugin keep
> changing from connectable to fast connectable multiple multiple times
> during the lifecycle and based on some specific policy.
That's correct.
> Can you give us some more background on how and when you change the
> modes here. Some simple flow-chart or so.
Fast connectable is switched on when incoming/outgoing call alerting
starts and respectively switched off when alerting stops (i.e. call is
answered/rejected/dropped) as it is implemented in telephony-maemo6
pluging.
The use case is that it enables shorter connection time when user
answers incoming call using headset when the headset is switched off
or disconnected.
>
>> > If we really wanna differentiate between connectable and fast
>> > connectable, then we need to fix up also the controller information to
>> > export this kind of detail. That will get pretty messy right now. So I
>> > would really just prefer to go with interlaced page scan by default an=
d
>> > see what downside this gives us.
>>
>> This is the way how fast connectable implementation is done currently
>> for hci_ops. It is disabled by default and default values for page
>> scan type and page scan interval are used. If one wishes to enable it,
>> audio.conf is used for that purpose. In that case, fast connectable
>> configuration is enabled during incoming/outgoing call alerting only.
>> In this case, connection initiated from headset side can be performed
>> much faster during that specific time interval.
>>
>> Hope this clarifies the questions. What do you think? Could you
>> elaborate more on 'then we need to fix up also the controller
>> information to export this kind of detail.'? Why that is needed?
>
> I like to figure out on what is the best interface to the kernel. Is
> this something really specific or should it be more generic. So for
> example program the page scan intervals into the kernel first. And then
> just toggle. Or have the interval as part of the command to toggle.
>
> And main concern is if multiple profiles wanna make us of it. How do we
> handle that part.
It seems like Claudio's input is quite crucial on how to align it with
LE. Looks like it is quite generic.
BR,
Dmitriy
Hi Dmitriy,
> >> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
> >> +struct mgmt_cp_set_fast_connectable {
> >> + __u8 enable;
> >> +} __packed;
> >> +
> >
> > so I am not 100% sure that doing it this way is the best way.
> >
> > What is the down side of just enabling interlaced page scan all the
> > time? And then maybe allow tuning of the timeout via debugfs for testing
> > purposes.
>
> This mode changes two parameters: page scan type and page scan
> interval. There two downsides to have those changed all the time:
> 1) power consumption
> 2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
>
> In this configuration page scanning happening during all dedicated
> slots and much more frequently. This is why probably it is not very
> good idea to have it enabled all the time, but only during short time
> interval when there are benefits out of such changes.
so the expectation is that bluetoothd or some sort of its plugin keep
changing from connectable to fast connectable multiple multiple times
during the lifecycle and based on some specific policy.
Can you give us some more background on how and when you change the
modes here. Some simple flow-chart or so.
> > If we really wanna differentiate between connectable and fast
> > connectable, then we need to fix up also the controller information to
> > export this kind of detail. That will get pretty messy right now. So I
> > would really just prefer to go with interlaced page scan by default and
> > see what downside this gives us.
>
> This is the way how fast connectable implementation is done currently
> for hci_ops. It is disabled by default and default values for page
> scan type and page scan interval are used. If one wishes to enable it,
> audio.conf is used for that purpose. In that case, fast connectable
> configuration is enabled during incoming/outgoing call alerting only.
> In this case, connection initiated from headset side can be performed
> much faster during that specific time interval.
>
> Hope this clarifies the questions. What do you think? Could you
> elaborate more on 'then we need to fix up also the controller
> information to export this kind of detail.'? Why that is needed?
I like to figure out on what is the best interface to the kernel. Is
this something really specific or should it be more generic. So for
example program the page scan intervals into the kernel first. And then
just toggle. Or have the interval as part of the command to toggle.
And main concern is if multiple profiles wanna make us of it. How do we
handle that part.
Regards
Marcel
Hi Marcel/Antti/Dmitriy,
On Mon, Jul 25, 2011 at 8:34 AM, Dmitriy Paliy <[email protected]> wr=
ote:
> Hi Marcel,
>
> On Wed, Jun 29, 2011 at 3:58 AM, Marcel Holtmann <[email protected]> wr=
ote:
>> Hi Antti,
>>
>>> Add command to management interface for enabling/disabling the
>>> fast connectable mode.
>>>
>>> Signed-off-by: Antti Julku <[email protected]>
>>> ---
>>> =C2=A0include/net/bluetooth/hci.h =C2=A0| =C2=A0 10 +++++++
>>> =C2=A0include/net/bluetooth/mgmt.h | =C2=A0 =C2=A05 +++
>>> =C2=A0net/bluetooth/mgmt.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 60 ++++=
++++++++++++++++++++++++++++++++++++++
>>> =C2=A03 files changed, 75 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>>> index 65345cd..d7b9600 100644
>>> --- a/include/net/bluetooth/hci.h
>>> +++ b/include/net/bluetooth/hci.h
>>> @@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
>>> =C2=A0 =C2=A0 =C2=A0 bdaddr_t bdaddr;
>>> =C2=A0} __packed;
>>>
>>> +#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY =C2=A0 =C2=A0 =C2=A00x0c1c
>>> +struct hci_cp_write_page_scan_activity {
>>> + =C2=A0 =C2=A0 __le16 =C2=A0 interval;
>>> + =C2=A0 =C2=A0 __le16 =C2=A0 window;
>>> +} __packed;
>>> +
>>> +#define HCI_OP_WRITE_PAGE_SCAN_TYPE =C2=A00x0c47
>>> + =C2=A0 =C2=A0 #define PAGE_SCAN_TYPE_STANDARD =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 0x00
>>> + =C2=A0 =C2=A0 #define PAGE_SCAN_TYPE_INTERLACED =C2=A0 =C2=A0 =C2=A0 =
0x01
>>> +
>>> =C2=A0#define HCI_OP_LE_SET_EVENT_MASK =C2=A0 =C2=A0 0x2001
>>> =C2=A0struct hci_cp_le_set_event_mask {
>>> =C2=A0 =C2=A0 =C2=A0 __u8 =C2=A0 =C2=A0 mask[8];
>>> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.=
h
>>> index 45bea25..7196d04 100644
>>> --- a/include/net/bluetooth/mgmt.h
>>> +++ b/include/net/bluetooth/mgmt.h
>>> @@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
>>> =C2=A0 =C2=A0 =C2=A0 bdaddr_t bdaddr;
>>> =C2=A0} __packed;
>>>
>>> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
>>> +struct mgmt_cp_set_fast_connectable {
>>> + =C2=A0 =C2=A0 __u8 enable;
>>> +} __packed;
>>> +
>>
>> so I am not 100% sure that doing it this way is the best way.
>>
>> What is the down side of just enabling interlaced page scan all the
>> time? And then maybe allow tuning of the timeout via debugfs for testing
>> purposes.
>
> This mode changes two parameters: page scan type and page scan
> interval. There two downsides to have those changed all the time:
> 1) power consumption
> 2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
>
> In this configuration page scanning happening during all dedicated
> slots and much more frequently. This is why probably it is not very
> good idea to have it enabled all the time, but only during short time
> interval when there are benefits out of such changes.
>
>> If we really wanna differentiate between connectable and fast
>> connectable, then we need to fix up also the controller information to
>> export this kind of detail. That will get pretty messy right now. So I
>> would really just prefer to go with interlaced page scan by default and
>> see what downside this gives us.
>
> This is the way how fast connectable implementation is done currently
> for hci_ops. It is disabled by default and default values for page
> scan type and page scan interval are used. If one wishes to enable it,
> audio.conf is used for that purpose. In that case, fast connectable
> configuration is enabled during incoming/outgoing call alerting only.
> In this case, connection initiated from headset side can be performed
> much faster during that specific time interval.
>
> Hope this clarifies the questions. What do you think? Could you
> elaborate more on 'then we need to fix up also the controller
> information to export this kind of detail.'? Why that is needed?
>
> BR,
> Dmitriy
BTW, I think we need to align BR and LE. Proximity and Thermometer
Profiles also have recommended parameters for fast connection(first
30sec) and 2 reduced power options. Both profiles use the same
configuration. If we add a new command to control page/connection
parameters it needs to be aligned with BR and LE and if possible
avoiding transport specific parameters.
BR,
Claudio
Hi Marcel,
On Wed, Jun 29, 2011 at 3:58 AM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Antti,
>
>> Add command to management interface for enabling/disabling the
>> fast connectable mode.
>>
>> Signed-off-by: Antti Julku <[email protected]>
>> ---
>> =A0include/net/bluetooth/hci.h =A0| =A0 10 +++++++
>> =A0include/net/bluetooth/mgmt.h | =A0 =A05 +++
>> =A0net/bluetooth/mgmt.c =A0 =A0 =A0 =A0 | =A0 60 +++++++++++++++++++++++=
+++++++++++++++++++
>> =A03 files changed, 75 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index 65345cd..d7b9600 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
>> =A0 =A0 =A0 bdaddr_t bdaddr;
>> =A0} __packed;
>>
>> +#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY =A0 =A0 =A00x0c1c
>> +struct hci_cp_write_page_scan_activity {
>> + =A0 =A0 __le16 =A0 interval;
>> + =A0 =A0 __le16 =A0 window;
>> +} __packed;
>> +
>> +#define HCI_OP_WRITE_PAGE_SCAN_TYPE =A00x0c47
>> + =A0 =A0 #define PAGE_SCAN_TYPE_STANDARD =A0 =A0 =A0 =A0 0x00
>> + =A0 =A0 #define PAGE_SCAN_TYPE_INTERLACED =A0 =A0 =A0 0x01
>> +
>> =A0#define HCI_OP_LE_SET_EVENT_MASK =A0 =A0 0x2001
>> =A0struct hci_cp_le_set_event_mask {
>> =A0 =A0 =A0 __u8 =A0 =A0 mask[8];
>> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
>> index 45bea25..7196d04 100644
>> --- a/include/net/bluetooth/mgmt.h
>> +++ b/include/net/bluetooth/mgmt.h
>> @@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
>> =A0 =A0 =A0 bdaddr_t bdaddr;
>> =A0} __packed;
>>
>> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
>> +struct mgmt_cp_set_fast_connectable {
>> + =A0 =A0 __u8 enable;
>> +} __packed;
>> +
>
> so I am not 100% sure that doing it this way is the best way.
>
> What is the down side of just enabling interlaced page scan all the
> time? And then maybe allow tuning of the timeout via debugfs for testing
> purposes.
This mode changes two parameters: page scan type and page scan
interval. There two downsides to have those changed all the time:
1) power consumption
2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
In this configuration page scanning happening during all dedicated
slots and much more frequently. This is why probably it is not very
good idea to have it enabled all the time, but only during short time
interval when there are benefits out of such changes.
> If we really wanna differentiate between connectable and fast
> connectable, then we need to fix up also the controller information to
> export this kind of detail. That will get pretty messy right now. So I
> would really just prefer to go with interlaced page scan by default and
> see what downside this gives us.
This is the way how fast connectable implementation is done currently
for hci_ops. It is disabled by default and default values for page
scan type and page scan interval are used. If one wishes to enable it,
audio.conf is used for that purpose. In that case, fast connectable
configuration is enabled during incoming/outgoing call alerting only.
In this case, connection initiated from headset side can be performed
much faster during that specific time interval.
Hope this clarifies the questions. What do you think? Could you
elaborate more on 'then we need to fix up also the controller
information to export this kind of detail.'? Why that is needed?
BR,
Dmitriy
Hi Gustavo,
On 08/22/2011 10:48 PM, ext Gustavo Padovan wrote:
>>>> Set Fast Connectable Command
>>>> ============================
>>>>
>>>> Command Code: 0x0001F
>>>> Controller Index:<controller id>
>>>> Command Parameters: Enable (1 Octet)
>>>> Return Parameters: Status (1 octet)
>>>>
>>>> Configure BR Fast Connectable Mode Command
>>>> ==========================================
>>>>
>>>> Command Code: 0x00020
>>>> Controller Index:<controller id>
>>>> Command Parameters: Page_scan_type (1 Octet)
>>>> Page_scan_interval (1 Octet)
>>>> Return Parameters: Status (1 octet)
>>>>
>>>> Configure LE Fast Connectable Mode Command
>>>> ==========================================
>>>>
>>>> Command Code: 0x00021
>>>> Controller Index:<controller id>
>>>> Command Parameters: Adv_interval (1 Octet)
>>>> ...and maybe some other settings if needed
>>>> Return Parameters: Status (1 octet)
>>>
>>> Can't both command be merged into one? LE Advertisement could be a scan type.
>>> But this won't work if we need more settings for LE.
>>>
>>> Gustavo
>>>
>>
>> Another input: for GATT based profiles after the disconnection the
>> specs are recommending advertising interval values for fast
>> reconnection in the first 30 seconds and reduced power mode after 30
>> seconds.
>> Of course, there are some implementations that disable advertising
>> after some time.
>>
>> At the moment, the incoming connection for dual mode device are not
>> allowed by the spec.
>>
>> My opinion is: parameters could be omitted. BR/EDR and LE could use
>> hard-coded settings for on/off of each transport. Add BR/EDR or LE
>> specific parameter in the Management interface commands doesn't look a
>> suitable approach. A simple on/off command seems to be more flexible
>> for future changes.
>
> Ok, so we could go only with Set Fast Connectable for now and use hardcoded
> values It's too early to say if we will need to to tune the those values for
> LE.
>
> Gustavo
So the initial fast connectable patch I sent is actually what we want?
Implementation for LE can be easily added later, when it's clear how LE
fast connectable should work. Please apply the patch then.
Br,
Antti
* Claudio Takahasi <[email protected]> [2011-08-22 15:40:53 -0=
300]:
> Hi guys,
>=20
> On Mon, Aug 22, 2011 at 3:01 PM, Gustavo Padovan <[email protected]>=
wrote:
> > Hi Antti,
> >
> > * Antti Julku <[email protected]> [2011-08-19 15:38:04 +0300]:
> >
> >>
> >> Hi Marcel,
> >>
> >> On 08/10/2011 04:55 PM, ext Marcel Holtmann wrote:
> >> >I recap, then fast connectable mode is something that is controlled by
> >> >one or multiple profiles. So this is just really a on/off switch. And=
if
> >> >we support it then all profiles should just use the same settings for
> >> >it. So far correct? Or do we need different values/parameters on a per
> >> >profile basis?
> >>
> >> All profiles use same settings currently, probably no need to have
> >> different configurations for profiles.
> >>
> >> >
> >> >If I just assume the above, then we need a set of commands that can
> >> >configure the settings of fast connectable mode. And that is done once
> >> >when we start bluetoothd. After that it is really just toggle on and
> >> >toggle off. And bluetoothd internally can keep a reference count for
> >> >that.
> >> >
> >> >And then it makes sense to do the same for LE and BR/EDR. It is either
> >> >on or off. Just the initial parameter set for LE is configured
> >> >differently.
> >>
> >> So one command which switches fast connectable on/off for both BR
> >> and LE? And two for configuration? =A0Maybe something like this?
> >>
> >> Set Fast Connectable Command
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> >>
> >> Command Code: =A0 =A0 =A0 =A0 =A0 0x0001F
> >> Controller Index: =A0 =A0 =A0 <controller id>
> >> Command Parameters: =A0 =A0 Enable (1 Octet)
> >> Return Parameters: =A0 =A0 =A0Status (1 octet)
> >>
> >> Configure BR Fast Connectable Mode Command
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> Command Code: =A0 =A0 =A0 =A0 =A0 0x00020
> >> Controller Index: =A0 =A0 =A0 <controller id>
> >> Command Parameters: =A0 =A0 Page_scan_type (1 Octet)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Page_scan_interval (1 =
Octet)
> >> Return Parameters: =A0 =A0 =A0Status (1 octet)
> >>
> >> Configure LE Fast Connectable Mode Command
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> Command Code: =A0 =A0 =A0 =A0 =A0 0x00021
> >> Controller Index: =A0 =A0 =A0 <controller id>
> >> Command Parameters: =A0 =A0 Adv_interval (1 Octet)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...and maybe some othe=
r settings if needed
> >> Return Parameters: =A0 =A0 =A0Status (1 octet)
> >
> > Can't both command be merged into one? LE Advertisement could be a scan=
type.
> > But this won't work if we need more settings for LE.
> >
> > =A0 =A0 =A0 =A0Gustavo
> >
>=20
> Another input: for GATT based profiles after the disconnection the
> specs are recommending advertising interval values for fast
> reconnection in the first 30 seconds and reduced power mode after 30
> seconds.
> Of course, there are some implementations that disable advertising
> after some time.
>=20
> At the moment, the incoming connection for dual mode device are not
> allowed by the spec.
>=20
> My opinion is: parameters could be omitted. BR/EDR and LE could use
> hard-coded settings for on/off of each transport. Add BR/EDR or LE
> specific parameter in the Management interface commands doesn't look a
> suitable approach. A simple on/off command seems to be more flexible
> for future changes.
Ok, so we could go only with Set Fast Connectable for now and use hardcoded
values It's too early to say if we will need to to tune the those values for
LE.
Gustavo
Hi guys,
On Mon, Aug 22, 2011 at 3:01 PM, Gustavo Padovan <[email protected]> w=
rote:
> Hi Antti,
>
> * Antti Julku <[email protected]> [2011-08-19 15:38:04 +0300]:
>
>>
>> Hi Marcel,
>>
>> On 08/10/2011 04:55 PM, ext Marcel Holtmann wrote:
>> >I recap, then fast connectable mode is something that is controlled by
>> >one or multiple profiles. So this is just really a on/off switch. And i=
f
>> >we support it then all profiles should just use the same settings for
>> >it. So far correct? Or do we need different values/parameters on a per
>> >profile basis?
>>
>> All profiles use same settings currently, probably no need to have
>> different configurations for profiles.
>>
>> >
>> >If I just assume the above, then we need a set of commands that can
>> >configure the settings of fast connectable mode. And that is done once
>> >when we start bluetoothd. After that it is really just toggle on and
>> >toggle off. And bluetoothd internally can keep a reference count for
>> >that.
>> >
>> >And then it makes sense to do the same for LE and BR/EDR. It is either
>> >on or off. Just the initial parameter set for LE is configured
>> >differently.
>>
>> So one command which switches fast connectable on/off for both BR
>> and LE? And two for configuration? =C2=A0Maybe something like this?
>>
>> Set Fast Connectable Command
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>>
>> Command Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0001F
>> Controller Index: =C2=A0 =C2=A0 =C2=A0 <controller id>
>> Command Parameters: =C2=A0 =C2=A0 Enable (1 Octet)
>> Return Parameters: =C2=A0 =C2=A0 =C2=A0Status (1 octet)
>>
>> Configure BR Fast Connectable Mode Command
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Command Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00020
>> Controller Index: =C2=A0 =C2=A0 =C2=A0 <controller id>
>> Command Parameters: =C2=A0 =C2=A0 Page_scan_type (1 Octet)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 Page_scan_interval (1 Octet)
>> Return Parameters: =C2=A0 =C2=A0 =C2=A0Status (1 octet)
>>
>> Configure LE Fast Connectable Mode Command
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Command Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00021
>> Controller Index: =C2=A0 =C2=A0 =C2=A0 <controller id>
>> Command Parameters: =C2=A0 =C2=A0 Adv_interval (1 Octet)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 ...and maybe some other settings if needed
>> Return Parameters: =C2=A0 =C2=A0 =C2=A0Status (1 octet)
>
> Can't both command be merged into one? LE Advertisement could be a scan t=
ype.
> But this won't work if we need more settings for LE.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Gustavo
>
Another input: for GATT based profiles after the disconnection the
specs are recommending advertising interval values for fast
reconnection in the first 30 seconds and reduced power mode after 30
seconds.
Of course, there are some implementations that disable advertising
after some time.
At the moment, the incoming connection for dual mode device are not
allowed by the spec.
My opinion is: parameters could be omitted. BR/EDR and LE could use
hard-coded settings for on/off of each transport. Add BR/EDR or LE
specific parameter in the Management interface commands doesn't look a
suitable approach. A simple on/off command seems to be more flexible
for future changes.
BR,
Claudio.
Hi Antti,
* Antti Julku <[email protected]> [2011-08-19 15:38:04 +0300]:
>
> Hi Marcel,
>
> On 08/10/2011 04:55 PM, ext Marcel Holtmann wrote:
> >I recap, then fast connectable mode is something that is controlled by
> >one or multiple profiles. So this is just really a on/off switch. And if
> >we support it then all profiles should just use the same settings for
> >it. So far correct? Or do we need different values/parameters on a per
> >profile basis?
>
> All profiles use same settings currently, probably no need to have
> different configurations for profiles.
>
> >
> >If I just assume the above, then we need a set of commands that can
> >configure the settings of fast connectable mode. And that is done once
> >when we start bluetoothd. After that it is really just toggle on and
> >toggle off. And bluetoothd internally can keep a reference count for
> >that.
> >
> >And then it makes sense to do the same for LE and BR/EDR. It is either
> >on or off. Just the initial parameter set for LE is configured
> >differently.
>
> So one command which switches fast connectable on/off for both BR
> and LE? And two for configuration? Maybe something like this?
>
> Set Fast Connectable Command
> ============================
>
> Command Code: 0x0001F
> Controller Index: <controller id>
> Command Parameters: Enable (1 Octet)
> Return Parameters: Status (1 octet)
>
> Configure BR Fast Connectable Mode Command
> ==========================================
>
> Command Code: 0x00020
> Controller Index: <controller id>
> Command Parameters: Page_scan_type (1 Octet)
> Page_scan_interval (1 Octet)
> Return Parameters: Status (1 octet)
>
> Configure LE Fast Connectable Mode Command
> ==========================================
>
> Command Code: 0x00021
> Controller Index: <controller id>
> Command Parameters: Adv_interval (1 Octet)
> ...and maybe some other settings if needed
> Return Parameters: Status (1 octet)
Can't both command be merged into one? LE Advertisement could be a scan type.
But this won't work if we need more settings for LE.
Gustavo
Hi Marcel,
On 08/10/2011 04:55 PM, ext Marcel Holtmann wrote:
> I recap, then fast connectable mode is something that is controlled by
> one or multiple profiles. So this is just really a on/off switch. And if
> we support it then all profiles should just use the same settings for
> it. So far correct? Or do we need different values/parameters on a per
> profile basis?
All profiles use same settings currently, probably no need to have
different configurations for profiles.
>
> If I just assume the above, then we need a set of commands that can
> configure the settings of fast connectable mode. And that is done once
> when we start bluetoothd. After that it is really just toggle on and
> toggle off. And bluetoothd internally can keep a reference count for
> that.
>
> And then it makes sense to do the same for LE and BR/EDR. It is either
> on or off. Just the initial parameter set for LE is configured
> differently.
So one command which switches fast connectable on/off for both BR and
LE? And two for configuration? Maybe something like this?
Set Fast Connectable Command
============================
Command Code: 0x0001F
Controller Index: <controller id>
Command Parameters: Enable (1 Octet)
Return Parameters: Status (1 octet)
Configure BR Fast Connectable Mode Command
==========================================
Command Code: 0x00020
Controller Index: <controller id>
Command Parameters: Page_scan_type (1 Octet)
Page_scan_interval (1 Octet)
Return Parameters: Status (1 octet)
Configure LE Fast Connectable Mode Command
==========================================
Command Code: 0x00021
Controller Index: <controller id>
Command Parameters: Adv_interval (1 Octet)
...and maybe some other settings if needed
Return Parameters: Status (1 octet)
I guess the default (fast connectable off) values can be hardcoded since
they should be always the same. We could also read the original value
before configuring, but then we can't know if it's really the default value.
Br,
Antti
Hi Antti,
> > This issue was discussed in the IRC. It seem that for LE, fast
> > connection is needed only on the initiator side for outgoing connections
> > (LE scan/connection establishment parameters), since 4.0 spec forbids LE
> > connections between dual mode devices. So fast connectable mode on the
> > LE acceptor side would be only used for testing purposes, or if spec is
> > changed, or if single mode hw is supported in the future.
> >
> > For BR/EDR, as Dmitriy explained, the fast connectable use case is to
> > make headset to be able to connect faster when there is an incoming call
> > (user switches headset on when call is alerting). It's an enhancement
> > for headset connection time and usability.
> >
> > It is currently implemented in hciops by changing page scan settings
> > while incoming call is alerting. HCI commands Write Page Scan Activity
> > and Write Page Scan Type are used to change page scan type from standard
> > to interlaced and interval 1.28 s => 22.5 ms. This makes the incoming
> > connection about 1 s faster. Settings are changed only for a short time
> > to minimize impact on power consumption.
> >
> > In my opinion BR and LE cases are quite different, so I think it would
> > make sense to keep these separate and not to put them in one mgmt
> > command. Could we just add a generic mgmt command for setting BR page
> > scan parameters, for example "Set Page Scan Parameters Command" which
> > would take parameters type (standard or interlaced), interval, and window?
> >
> > Br,
> > Antti
>
> Any comments on this one? There has been lot of ideas about how the
> "fast connectable mode" for incoming connections should be implemented
> for management interface, and whether the same mgmt command should be
> used for both BR and LE. It's not totally clear yet what is needed for
> LE, but at least the Proximity profile requires changing the advertising
> parameters to make connecting faster.
>
> Which option do you prefer?
>
> 1) Unified mgmt command for both BR and LE: fast connectable mode toggling.
> + simple interface for both BR and LE
> - scan/advertising parameters are hardcoded to kernel
> - BR page scan and LE advertising are two different things, why to mix
> them in same mgmt command?
> - not even needed currently by LE: only if single mode dongles will be
> supported, or spec is changed to allow dual mode device to accept LE
> connections
>
> 2) Command for BR and LE as in option 1, in addition we could define 3
> values. e.g. slow, normal, fast.
> + flexible to support LE advertising settings (when we support single
> mode dongles)
>
> 3) The patch I sent, fast connectable mode only for BR. If on/off
> toggling is enough for LE, it's easy to add LE support later.
>
> 4) Mgmt command for setting parameters for BR/LE/both to kernel, and
> another for toggling fast connectable on/off
> + more flexible than just toggling
> - two mgmt commands needed
>
> 5) Mgmt command for changing BR page scan parameters, e.g "Set Page Scan
> Parameters".
> + simplest solution for BR, since it's currently only needed for
> optimizing scan parameters for HFP connections
> + generic interface which can be used also for other purposes, no need
> to have concept of "fast connectable mode" in the kernel
> + more flexible for user space, if values need to be changed, or
> optimized for another purpose
> - too low level stuff for mgmt interface?
> - another solution needed for LE
>
> 6) Something else.
I recap, then fast connectable mode is something that is controlled by
one or multiple profiles. So this is just really a on/off switch. And if
we support it then all profiles should just use the same settings for
it. So far correct? Or do we need different values/parameters on a per
profile basis?
If I just assume the above, then we need a set of commands that can
configure the settings of fast connectable mode. And that is done once
when we start bluetoothd. After that it is really just toggle on and
toggle off. And bluetoothd internally can keep a reference count for
that.
And then it makes sense to do the same for LE and BR/EDR. It is either
on or off. Just the initial parameter set for LE is configured
differently.
Regards
Marcel
Hello Marcel and Johan,
On 08/04/2011 11:44 AM, Antti Julku wrote:
>
> This issue was discussed in the IRC. It seem that for LE, fast
> connection is needed only on the initiator side for outgoing connections
> (LE scan/connection establishment parameters), since 4.0 spec forbids LE
> connections between dual mode devices. So fast connectable mode on the
> LE acceptor side would be only used for testing purposes, or if spec is
> changed, or if single mode hw is supported in the future.
>
> For BR/EDR, as Dmitriy explained, the fast connectable use case is to
> make headset to be able to connect faster when there is an incoming call
> (user switches headset on when call is alerting). It's an enhancement
> for headset connection time and usability.
>
> It is currently implemented in hciops by changing page scan settings
> while incoming call is alerting. HCI commands Write Page Scan Activity
> and Write Page Scan Type are used to change page scan type from standard
> to interlaced and interval 1.28 s => 22.5 ms. This makes the incoming
> connection about 1 s faster. Settings are changed only for a short time
> to minimize impact on power consumption.
>
> In my opinion BR and LE cases are quite different, so I think it would
> make sense to keep these separate and not to put them in one mgmt
> command. Could we just add a generic mgmt command for setting BR page
> scan parameters, for example "Set Page Scan Parameters Command" which
> would take parameters type (standard or interlaced), interval, and window?
>
> Br,
> Antti
Any comments on this one? There has been lot of ideas about how the
"fast connectable mode" for incoming connections should be implemented
for management interface, and whether the same mgmt command should be
used for both BR and LE. It's not totally clear yet what is needed for
LE, but at least the Proximity profile requires changing the advertising
parameters to make connecting faster.
Which option do you prefer?
1) Unified mgmt command for both BR and LE: fast connectable mode toggling.
+ simple interface for both BR and LE
- scan/advertising parameters are hardcoded to kernel
- BR page scan and LE advertising are two different things, why to mix
them in same mgmt command?
- not even needed currently by LE: only if single mode dongles will be
supported, or spec is changed to allow dual mode device to accept LE
connections
2) Command for BR and LE as in option 1, in addition we could define 3
values. e.g. slow, normal, fast.
+ flexible to support LE advertising settings (when we support single
mode dongles)
3) The patch I sent, fast connectable mode only for BR. If on/off
toggling is enough for LE, it's easy to add LE support later.
4) Mgmt command for setting parameters for BR/LE/both to kernel, and
another for toggling fast connectable on/off
+ more flexible than just toggling
- two mgmt commands needed
5) Mgmt command for changing BR page scan parameters, e.g "Set Page Scan
Parameters".
+ simplest solution for BR, since it's currently only needed for
optimizing scan parameters for HFP connections
+ generic interface which can be used also for other purposes, no need
to have concept of "fast connectable mode" in the kernel
+ more flexible for user space, if values need to be changed, or
optimized for another purpose
- too low level stuff for mgmt interface?
- another solution needed for LE
6) Something else.
Br,
Antti
Hi Claudio and Marcel,
On 07/25/2011 03:46 PM, ext Claudio Takahasi wrote:
> BTW, I think we need to align BR and LE. Proximity and Thermometer
> Profiles also have recommended parameters for fast connection(first
> 30sec) and 2 reduced power options. Both profiles use the same
> configuration. If we add a new command to control page/connection
> parameters it needs to be aligned with BR and LE and if possible
> avoiding transport specific parameters.
>
> BR,
> Claudio
This issue was discussed in the IRC. It seem that for LE, fast
connection is needed only on the initiator side for outgoing connections
(LE scan/connection establishment parameters), since 4.0 spec forbids LE
connections between dual mode devices. So fast connectable mode on the
LE acceptor side would be only used for testing purposes, or if spec is
changed, or if single mode hw is supported in the future.
For BR/EDR, as Dmitriy explained, the fast connectable use case is to
make headset to be able to connect faster when there is an incoming call
(user switches headset on when call is alerting). It's an enhancement
for headset connection time and usability.
It is currently implemented in hciops by changing page scan settings
while incoming call is alerting. HCI commands Write Page Scan Activity
and Write Page Scan Type are used to change page scan type from standard
to interlaced and interval 1.28 s => 22.5 ms. This makes the incoming
connection about 1 s faster. Settings are changed only for a short time
to minimize impact on power consumption.
In my opinion BR and LE cases are quite different, so I think it would
make sense to keep these separate and not to put them in one mgmt
command. Could we just add a generic mgmt command for setting BR page
scan parameters, for example "Set Page Scan Parameters Command" which
would take parameters type (standard or interlaced), interval, and window?
Br,
Antti