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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
