RE: CSA2: User space aspect
From: Michael Knudsen <hidden>
Date: 2012-11-15 11:34:48
please to not attempt to use socket options as ioctl. They are called options for a reason. Getting the list of supported codecs should be done via mgmt interface command and it should be only done once.
Okay, I'll take a stab at this, then. I expect that socket options are still fine for actually setting the configuration?
Please ask yourself the question when and how the SCO data from the socket is actually affected. I still have not seen you provide the semantics of how the socket would be used afterwards. Especially on impact for the application establishing the SCO socket.
There are two cases, connect() and accept(). For connect(), this is pretty simple: sk = socket(..); setsockopt(sk, SOL_SCO, SCO_AIR_FORMAT, ...); connect(sk, ..); For accept(), it is the intention that this will be used in conjunction with BT_DEFER_SETUP such that we can set the codecs as per how we just negotiated with the peer: sk = socket(..); bind(sk, ..); setsockopt(sk, SOL_SCO, BT_DEFER_SETUP, 1); listen(sk, ..); peer = accept(sk, ..); setsockopt(peer, SOL_SCO, SCO_AIR_FORMAT, SCO_FORMAT_MSBC); recvmsg(peer, ..);
In a more important question, is this static one time fits all selection or is this actually to be dynamic on every new connection establishment.
Both (defer/non-defer). The socket options will set the parameters that are used by the stack whenever it sets up or accepts a connection. Did this answer your questions? -m.