Hi Marcel,
On 10/02/17 11:30, Marcel Holtmann wrote:
> Hi Felipe,
>
>> There is a need for certain LE profiles (MIDI for example)to change the
>> current connection's parameters. In order to do that, this patch
>> introduces a new BT_LE_CONN_PARAM socket option for SOL_BLUETOOTH
>> protocol which allow user-space l2cap sockets to update the current
>> connection.
>>
>> This option will also send a MGMT_EV_NEW_CONN_PARAM event with the
>> store_hint set so the user-space application can store the connection
>> parameters for persistence reasons.
>>
>> Signed-off-by: Felipe F. Tonello <eu@xxxxxxxxxxxxxxxxx>
>> ---
>> include/net/bluetooth/bluetooth.h | 8 ++++
>> net/bluetooth/l2cap_sock.c | 98 +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 106 insertions(+)
>>
>> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
>> index 01487192f628..ce5b3abd3b27 100644
>> --- a/include/net/bluetooth/bluetooth.h
>> +++ b/include/net/bluetooth/bluetooth.h
>> @@ -122,6 +122,14 @@ struct bt_voice {
>> #define BT_SNDMTU 12
>> #define BT_RCVMTU 13
>>
>> +#define BT_LE_CONN_PARAM 14
>> +struct bt_le_conn_param {
>> + __u16 min_interval;
>> + __u16 max_interval;
>> + __u16 latency;
>> + __u16 supervision_timeout;
>> +};
>> +
>
> I am not 100% convinced that we want this level of detail exposed to user space. I was more thinking of having two or three sets of connection parameters and then a simple enum via socket option to choose from.
>
> We have the default value that we use for everything right now. And then we can have a high latency and low latency setting to change that. The supervision timeout is a different story since that would also apply to BR/EDR and we could allow for individual setting of that.
Ok, so we could have:
- LOW_LATENCY: minimum possible values
- DEFAULT_LATENCY: default
- HIGH_LATENCY: Maximum possible values
When you say latency, do you only refer to the latency field or the
min/max_interval too?
>
> The reason we store the exact connection parameters via mgmt is so that next time around, the slave does not have to request new ones. We already use the correct ones from the get go. One thing we are missing is to actually pick them up from advertising report. Since they can also be reported that way.
Ok, but what about the Master? Are you talking about the
LL_CONNECTION_PARAM_REQ procedure from 4.1? If so, it should work both
ways, right?
>
> Also with a socket option we have to be careful that multiple sockets might want to program different values.
Right. That can be handled in bluetoothd, probably.
> We do support connection oriented channels with LE. Otherwise this would have to artificially restricted to GATT CID for now.
How would this affect? Sorry, I am not familiar with CoC.
> And even there is still the case between connect() and accept(). Also that accept() is use with the background connection.
What is the case between connect() and accept()?
> I mean on an outgoing connection, I want to be able to influence the settings before calling connect() so they are used directly in the LE_Create_Connection command. Especially if I already know what I am creating the connection for.
Yes, in the case the connection parameter is in the advertising data, we
can definitely do it. Perhaps saving in the device info file before the
device_create() in bluetoothd is called.
But like I said, there is also the case where the slave doesn't provide
this information and the connection needs to be updated anyway based on
the profile (which is my use-case after all).
====
TBH I am very confused with all the possible ways slave and master can
update its connection parameters and vice-versa. It also has differences
between 4.0 and 4.1 and greater.
Could we list these first and so we have a clear picture on what it
needs to be done?
Thanks
--
Felipe
Attachment:
0x92698E6A.asc
Description: application/pgp-keys
