Hello,
I've been working on the MIDI profile plugin for bluetoothd. This
profile requires the lowest latency and connection interval possible. In
order to do that we need to update the connection parameters. There are
two ways of doing it, first is upon connection
(HCI_LE_Create_Connection) and second is updating current connection
link (HCI_LE_Connection_Update).
The first time an LE slave (MIDI controller) device is connected to
BlueZ, the plugin should be able to set this parameters for current
connection and save these settings for persistence purposes.
As of today, bluetoothd does support the persistence mechanist, which is
triggered by a mgmt's New Connection Parameter (0x001c) command, which
in turn is triggered by L2CAP Connection Parameter Update Request or a
HCI LE Remote Connection Parameter Request (BT 4.1).
As mentioned before, this is not enough. Specially because in practice
LE slave devices don't send a any of those two requests mentioned above.
My idea is to set the connection parameter using
HCI_LE_Connection_Update if one of the host controllers, master or
slave, only supports 4.0. Then update the device info file with current
ConnectionParameters for persistence.
In case both controllers support 4.1 and above, we should use the
Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
order to negotiate what is the best parameters for the connection.
I hope this makes sense. If not, I appreciate your comments. :)
--
Felipe
Hi Luiz,
On 03/02/17 19:31, Luiz Augusto von Dentz wrote:
> Hi Felipe,
>
> On Fri, Feb 3, 2017 at 8:23 PM, Felipe Ferreri Tonello
> <[email protected]> wrote:
>> Hi Marcel,
>>
>> On 02/02/17 10:30, Marcel Holtmann wrote:
>>> Hi Felipe,
>>>
>>>>>> I've been working on the MIDI profile plugin for bluetoothd. This
>>>>>> profile requires the lowest latency and connection interval possible. In
>>>>>> order to do that we need to update the connection parameters. There are
>>>>>> two ways of doing it, first is upon connection
>>>>>> (HCI_LE_Create_Connection) and second is updating current connection
>>>>>> link (HCI_LE_Connection_Update).
>>>>>>
>>>>>> The first time an LE slave (MIDI controller) device is connected to
>>>>>> BlueZ, the plugin should be able to set this parameters for current
>>>>>> connection and save these settings for persistence purposes.
>>>>>>
>>>>>> As of today, bluetoothd does support the persistence mechanist, which is
>>>>>> triggered by a mgmt's New Connection Parameter (0x001c) command, which
>>>>>> in turn is triggered by L2CAP Connection Parameter Update Request or a
>>>>>> HCI LE Remote Connection Parameter Request (BT 4.1).
>>>>>>
>>>>>> As mentioned before, this is not enough. Specially because in practice
>>>>>> LE slave devices don't send a any of those two requests mentioned above.
>>>>>>
>>>>>> My idea is to set the connection parameter using
>>>>>> HCI_LE_Connection_Update if one of the host controllers, master or
>>>>>> slave, only supports 4.0. Then update the device info file with current
>>>>>> ConnectionParameters for persistence.
>>>>>>
>>>>>> In case both controllers support 4.1 and above, we should use the
>>>>>> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
>>>>>> order to negotiate what is the best parameters for the connection.
>>>>>>
>>>>>> I hope this makes sense. If not, I appreciate your comments. :)
>>>>>
>>>>> we need to introduce a L2CAP socket option that allows for setting some of the connection parameters. So that the kernel can consolidate these and request them.
>>>>
>>>> Yes, this sounds great. What would you recommend to implement then?
>>>> Using SOL_L2CAP or SOL_SOCKET with a new optname?
>>>
>>> we want to use SOL_BLUETOOTH. Unless there is a common SOL_SOCKET that would map here, but I hight doubt that is the case.
>>>
>>>>> I am not 100% we want to expose the actual values. Maybe it is better to have a latency parameter with high, default and low as values.
>>>>>
>>>>
>>>> Yes.
>>>>
>>>> What would this option trigger the controller to do? Because as I have
>>>> seen it really depends on HCI role and BT version, but I am not an
>>>> expert in BT, so I appreciate any comments.
>>>
>>> It should not matter from the API point of view if you do this as slave or master. However inside the kernel, it needs to map to the right connection update procedure.
>>
>> Right, but if there is a socket option for a l2cap socket, why then
>> have a MGMT command for updating the connection parameter?
>
> Btw, for outgoing connection we might want to trigger the right
> parameters from the connection request, just as it is done when they
> are loaded using Load Connection Parameters Command, anyway this
> should cause the New Connection Parameter Event so the next time we
> attempt to connect it should come back with the same parameters agreed
> on the last connection. Also note that for passive scanning/auto
> connect we would have to use the socket options on the listening
> socket which is per adapter not per device, so it wont be possible to
> consult the parameters from the socket requesting the ACL to be
> connected.
>
Yes, that is how I am doing so far. I have a code working and I'll send
an RFC to see what you guys think.
--
Felipe
Hi Felipe,
On Fri, Feb 3, 2017 at 8:23 PM, Felipe Ferreri Tonello
<[email protected]> wrote:
> Hi Marcel,
>
> On 02/02/17 10:30, Marcel Holtmann wrote:
>> Hi Felipe,
>>
>>>>> I've been working on the MIDI profile plugin for bluetoothd. This
>>>>> profile requires the lowest latency and connection interval possible.=
In
>>>>> order to do that we need to update the connection parameters. There a=
re
>>>>> two ways of doing it, first is upon connection
>>>>> (HCI_LE_Create_Connection) and second is updating current connection
>>>>> link (HCI_LE_Connection_Update).
>>>>>
>>>>> The first time an LE slave (MIDI controller) device is connected to
>>>>> BlueZ, the plugin should be able to set this parameters for current
>>>>> connection and save these settings for persistence purposes.
>>>>>
>>>>> As of today, bluetoothd does support the persistence mechanist, which=
is
>>>>> triggered by a mgmt's New Connection Parameter (0x001c) command, whic=
h
>>>>> in turn is triggered by L2CAP Connection Parameter Update Request or =
a
>>>>> HCI LE Remote Connection Parameter Request (BT 4.1).
>>>>>
>>>>> As mentioned before, this is not enough. Specially because in practic=
e
>>>>> LE slave devices don't send a any of those two requests mentioned abo=
ve.
>>>>>
>>>>> My idea is to set the connection parameter using
>>>>> HCI_LE_Connection_Update if one of the host controllers, master or
>>>>> slave, only supports 4.0. Then update the device info file with curre=
nt
>>>>> ConnectionParameters for persistence.
>>>>>
>>>>> In case both controllers support 4.1 and above, we should use the
>>>>> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B =C2=A75.=
1.17) in
>>>>> order to negotiate what is the best parameters for the connection.
>>>>>
>>>>> I hope this makes sense. If not, I appreciate your comments. :)
>>>>
>>>> we need to introduce a L2CAP socket option that allows for setting som=
e of the connection parameters. So that the kernel can consolidate these an=
d request them.
>>>
>>> Yes, this sounds great. What would you recommend to implement then?
>>> Using SOL_L2CAP or SOL_SOCKET with a new optname?
>>
>> we want to use SOL_BLUETOOTH. Unless there is a common SOL_SOCKET that w=
ould map here, but I hight doubt that is the case.
>>
>>>> I am not 100% we want to expose the actual values. Maybe it is better =
to have a latency parameter with high, default and low as values.
>>>>
>>>
>>> Yes.
>>>
>>> What would this option trigger the controller to do? Because as I have
>>> seen it really depends on HCI role and BT version, but I am not an
>>> expert in BT, so I appreciate any comments.
>>
>> It should not matter from the API point of view if you do this as slave =
or master. However inside the kernel, it needs to map to the right connecti=
on update procedure.
>
> Right, but if there is a socket option for a l2cap socket, why then
> have a MGMT command for updating the connection parameter?
Btw, for outgoing connection we might want to trigger the right
parameters from the connection request, just as it is done when they
are loaded using Load Connection Parameters Command, anyway this
should cause the New Connection Parameter Event so the next time we
attempt to connect it should come back with the same parameters agreed
on the last connection. Also note that for passive scanning/auto
connect we would have to use the socket options on the listening
socket which is per adapter not per device, so it wont be possible to
consult the parameters from the socket requesting the ACL to be
connected.
--=20
Luiz Augusto von Dentz
Hi Marcel,
On 02/02/17 10:30, Marcel Holtmann wrote:
> Hi Felipe,
>
>>>> I've been working on the MIDI profile plugin for bluetoothd. This
>>>> profile requires the lowest latency and connection interval possible. In
>>>> order to do that we need to update the connection parameters. There are
>>>> two ways of doing it, first is upon connection
>>>> (HCI_LE_Create_Connection) and second is updating current connection
>>>> link (HCI_LE_Connection_Update).
>>>>
>>>> The first time an LE slave (MIDI controller) device is connected to
>>>> BlueZ, the plugin should be able to set this parameters for current
>>>> connection and save these settings for persistence purposes.
>>>>
>>>> As of today, bluetoothd does support the persistence mechanist, which is
>>>> triggered by a mgmt's New Connection Parameter (0x001c) command, which
>>>> in turn is triggered by L2CAP Connection Parameter Update Request or a
>>>> HCI LE Remote Connection Parameter Request (BT 4.1).
>>>>
>>>> As mentioned before, this is not enough. Specially because in practice
>>>> LE slave devices don't send a any of those two requests mentioned above.
>>>>
>>>> My idea is to set the connection parameter using
>>>> HCI_LE_Connection_Update if one of the host controllers, master or
>>>> slave, only supports 4.0. Then update the device info file with current
>>>> ConnectionParameters for persistence.
>>>>
>>>> In case both controllers support 4.1 and above, we should use the
>>>> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
>>>> order to negotiate what is the best parameters for the connection.
>>>>
>>>> I hope this makes sense. If not, I appreciate your comments. :)
>>>
>>> we need to introduce a L2CAP socket option that allows for setting some of the connection parameters. So that the kernel can consolidate these and request them.
>>
>> Yes, this sounds great. What would you recommend to implement then?
>> Using SOL_L2CAP or SOL_SOCKET with a new optname?
>
> we want to use SOL_BLUETOOTH. Unless there is a common SOL_SOCKET that would map here, but I hight doubt that is the case.
>
>>> I am not 100% we want to expose the actual values. Maybe it is better to have a latency parameter with high, default and low as values.
>>>
>>
>> Yes.
>>
>> What would this option trigger the controller to do? Because as I have
>> seen it really depends on HCI role and BT version, but I am not an
>> expert in BT, so I appreciate any comments.
>
> It should not matter from the API point of view if you do this as slave or master. However inside the kernel, it needs to map to the right connection update procedure.
Right, but if there is a socket option for a l2cap socket, why then
have a MGMT command for updating the connection parameter?
--
Felipe
Hi Felipe,
>>> I've been working on the MIDI profile plugin for bluetoothd. This
>>> profile requires the lowest latency and connection interval possible. In
>>> order to do that we need to update the connection parameters. There are
>>> two ways of doing it, first is upon connection
>>> (HCI_LE_Create_Connection) and second is updating current connection
>>> link (HCI_LE_Connection_Update).
>>>
>>> The first time an LE slave (MIDI controller) device is connected to
>>> BlueZ, the plugin should be able to set this parameters for current
>>> connection and save these settings for persistence purposes.
>>>
>>> As of today, bluetoothd does support the persistence mechanist, which is
>>> triggered by a mgmt's New Connection Parameter (0x001c) command, which
>>> in turn is triggered by L2CAP Connection Parameter Update Request or a
>>> HCI LE Remote Connection Parameter Request (BT 4.1).
>>>
>>> As mentioned before, this is not enough. Specially because in practice
>>> LE slave devices don't send a any of those two requests mentioned above.
>>>
>>> My idea is to set the connection parameter using
>>> HCI_LE_Connection_Update if one of the host controllers, master or
>>> slave, only supports 4.0. Then update the device info file with current
>>> ConnectionParameters for persistence.
>>>
>>> In case both controllers support 4.1 and above, we should use the
>>> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
>>> order to negotiate what is the best parameters for the connection.
>>>
>>> I hope this makes sense. If not, I appreciate your comments. :)
>>
>> we need to introduce a L2CAP socket option that allows for setting some of the connection parameters. So that the kernel can consolidate these and request them.
>
> Yes, this sounds great. What would you recommend to implement then?
> Using SOL_L2CAP or SOL_SOCKET with a new optname?
we want to use SOL_BLUETOOTH. Unless there is a common SOL_SOCKET that would map here, but I hight doubt that is the case.
>> I am not 100% we want to expose the actual values. Maybe it is better to have a latency parameter with high, default and low as values.
>>
>
> Yes.
>
> What would this option trigger the controller to do? Because as I have
> seen it really depends on HCI role and BT version, but I am not an
> expert in BT, so I appreciate any comments.
It should not matter from the API point of view if you do this as slave or master. However inside the kernel, it needs to map to the right connection update procedure.
Regards
Marcel
Hi Marcel,
On 01/02/17 19:38, Marcel Holtmann wrote:
> Hi Filipe,
>
>> I've been working on the MIDI profile plugin for bluetoothd. This
>> profile requires the lowest latency and connection interval possible. In
>> order to do that we need to update the connection parameters. There are
>> two ways of doing it, first is upon connection
>> (HCI_LE_Create_Connection) and second is updating current connection
>> link (HCI_LE_Connection_Update).
>>
>> The first time an LE slave (MIDI controller) device is connected to
>> BlueZ, the plugin should be able to set this parameters for current
>> connection and save these settings for persistence purposes.
>>
>> As of today, bluetoothd does support the persistence mechanist, which is
>> triggered by a mgmt's New Connection Parameter (0x001c) command, which
>> in turn is triggered by L2CAP Connection Parameter Update Request or a
>> HCI LE Remote Connection Parameter Request (BT 4.1).
>>
>> As mentioned before, this is not enough. Specially because in practice
>> LE slave devices don't send a any of those two requests mentioned above.
>>
>> My idea is to set the connection parameter using
>> HCI_LE_Connection_Update if one of the host controllers, master or
>> slave, only supports 4.0. Then update the device info file with current
>> ConnectionParameters for persistence.
>>
>> In case both controllers support 4.1 and above, we should use the
>> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
>> order to negotiate what is the best parameters for the connection.
>>
>> I hope this makes sense. If not, I appreciate your comments. :)
>
> we need to introduce a L2CAP socket option that allows for setting some of the connection parameters. So that the kernel can consolidate these and request them.
Yes, this sounds great. What would you recommend to implement then?
Using SOL_L2CAP or SOL_SOCKET with a new optname?
>
> I am not 100% we want to expose the actual values. Maybe it is better to have a latency parameter with high, default and low as values.
>
Yes.
What would this option trigger the controller to do? Because as I have
seen it really depends on HCI role and BT version, but I am not an
expert in BT, so I appreciate any comments.
--
Felipe
Hi Filipe,
> I've been working on the MIDI profile plugin for bluetoothd. This
> profile requires the lowest latency and connection interval possible. In
> order to do that we need to update the connection parameters. There are
> two ways of doing it, first is upon connection
> (HCI_LE_Create_Connection) and second is updating current connection
> link (HCI_LE_Connection_Update).
>
> The first time an LE slave (MIDI controller) device is connected to
> BlueZ, the plugin should be able to set this parameters for current
> connection and save these settings for persistence purposes.
>
> As of today, bluetoothd does support the persistence mechanist, which is
> triggered by a mgmt's New Connection Parameter (0x001c) command, which
> in turn is triggered by L2CAP Connection Parameter Update Request or a
> HCI LE Remote Connection Parameter Request (BT 4.1).
>
> As mentioned before, this is not enough. Specially because in practice
> LE slave devices don't send a any of those two requests mentioned above.
>
> My idea is to set the connection parameter using
> HCI_LE_Connection_Update if one of the host controllers, master or
> slave, only supports 4.0. Then update the device info file with current
> ConnectionParameters for persistence.
>
> In case both controllers support 4.1 and above, we should use the
> Connection Parameters Request Procedure (BT 4.1 Vol 6 Part B §5.1.17) in
> order to negotiate what is the best parameters for the connection.
>
> I hope this makes sense. If not, I appreciate your comments. :)
we need to introduce a L2CAP socket option that allows for setting some of the connection parameters. So that the kernel can consolidate these and request them.
I am not 100% we want to expose the actual values. Maybe it is better to have a latency parameter with high, default and low as values.
Regards
Marcel