Re: Update the connection's parameters

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
[off-list ref] wrote:

quoted

Hi Marcel,

On 02/02/17 10:30, Marcel Holtmann wrote:

quoted

Hi Felipe,

quoted

quoted

quoted

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.

quoted

quoted

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