Re: CSA2: User space aspect

[Marcel Holtmann <marcel@holtmann.org>]

Hi Michael,

> > If anyone else has an ideas or opinions about this, please speak up,
> > otherwise I'll try coming up with an interface specification with
> > more details.
> 
> This diff shows the direction I'm heading:
> 
> diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
> index 1e35c43..a565a4d 100644
> --- a/include/net/bluetooth/sco.h
> +++ b/include/net/bluetooth/sco.h
> @@ -51,6 +51,42 @@ struct sco_conninfo {
>  	__u8  dev_class[3];
>  };
>  
> +/* Audio format setting */
> +#define SCO_HOST_FORMAT	0x04
> +#define SCO_AIR_FORMAT	0x05
> +
> +#define SCO_FORMAT_ULAW		0x00
> +#define SCO_FORMAT_ALAW		0x01
> +#define SCO_FORMAT_CVSD		0x02
> +#define SCO_FORMAT_TRANSPARENT	0x03 
> +#define SCO_FORMAT_PCM		0x05 
> +#define SCO_FORMAT_MSBC		0x05 
> +#define SCO_FORMAT_VENDOR	0xff
> +struct sco_format_vendor {
> +	__u16 vendor;
> +	__u16 codec;
> +};
> +
> +struct sco_format {
> +	__u8                     in_format;
> +	struct sco_format_vendor in_vendor;
> +
> +	__u8                     out_format;
> +	struct sco_format_vendor out_vendor;
> +};
> +
> +#define SCO_CODECS		0x06
> +struct sco_codecs {
> +	__u8  count;
> +	__u8 *codec;
> +};
> +
> +#define SCO_CODECS_VENDOR	0x07
> +struct sco_codecs_vendor {
> +	__u8                      count;
> +	struct sco_format_vendor *format;
> +};
> +
>  /* ---- SCO connections ---- */
>  struct sco_conn {
>  	struct hci_conn	*hcon;
> @@ -74,6 +110,8 @@ struct sco_pinfo {
>  	struct bt_sock	bt;
>  	__u32		flags;
>  	struct sco_conn	*conn;
> +	struct sco_format host_format;
> +	struct sco_format air_format;
>  };
>  
>  #endif /* __SCO_H */
> 
> Basically, this adds four socket options (I'll do the audio path
> stuff as well once this is done):
> 
> 	SCO_AIR_FORMAT
> 	SCO_HOST_FORMAT
> 	SCO_CODECS (ro)
> 	SCO_CODECS_VENDOR (ro)
> 
> The SCO_CODECS ones provide the application with a list of codecs
> supported by the hdev as indicated in the HCI_Read_Local_Supported_Codecs
> command response, and if the hdev does not support this command a
> default of linear PCM, CVSD, and transparent will be provided.

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.

> Because the result length is variable, the idea is that the application-
> provided structure is modified by the kernel to hold the actual number
> of results so the application can allocate a buffer accordingly, e.g.:
> 
> 	struct sco_codecs sc;
> 	
> 	memset(&sc, 0, sizeof(sc));
> 	getsockopt(sk, SOL_SCO, SCO_CODECS, &sk);
> 
> 	sk.codecs = malloc(sk.count);
> 	getsockopt(sk, SOL_SCO, SCO_CODECS, &sk);

We are not doing that. I have no intention to map kernel memory to
userspace memory and back with socket options.

> The SCO_*_FORMAT ones allows the application to set the parameters that
> are to be used on host-controller and controller-controller paths.  While
> the spec requires the pairs (host input/output, air input/output) to be
> identical, I don't see a reason to enforce this in the API, thus all are
> set independently.
> 
> So, before I spend any more time on this.. comments?

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.

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.

Regards

Marcel