linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Nick Pelly <npelly@google.com>
Cc: Ville Tervo <ville.tervo@nokia.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.
Date: Wed, 17 Feb 2010 09:31:34 -0800	[thread overview]
Message-ID: <1266427894.8849.66.camel@localhost.localdomain> (raw)
In-Reply-To: <35c90d961002170849m1d13743fg725a87594d63b80c@mail.gmail.com>

Hi Nick,

> >> As a first step, can we get consensus on the userspace API:
> >>
> >> --- a/include/net/bluetooth/hci.h
> >> +++ b/include/net/bluetooth/hci.h
> >> @@ -139,8 +139,11 @@ enum {
> >> +#define ALL_SCO_PKTS   (SCO_ESCO_MASK | EDR_ESCO_MASK)
> >> +#define ALL_ESCO_PKTS  (SCO_ESCO_MASK | ESCO_EV3 | ESCO_EV4 | ESCO_EV5)
> >>
> >> --- a/include/net/bluetooth/sco.h
> >> +++ b/include/net/bluetooth/sco.h
> >> @@ -37,6 +37,7 @@
> >> struct sockaddr_sco {
> >>       sa_family_t     sco_family;
> >>       bdaddr_t        sco_bdaddr;
> >> +       __u16           sco_pkt_type;
> >> };
> >>
> >> This will at least unblock my work.
> >
> > Would it be better to add new sockopt for sco socket?
> 
> What advantage does that have?
> 
> Putting it in struct sockaddr_sco seems to make more sense since
> packet types can only be selected during SCO connection establishment.
> They can't be changed once the socket is connected.

in theory you can change the allowed packet types for ACL, SCO and eSCO
after the connection is active. However the usefulness here is fairly
limited. In case of ACL it is purely academical and most link manager
will just ignore you. Mainly because the host stack can't really make a
good decision here anyway.

Personally I think it is a total brain dead concept to give this into
the control of the host stack anyway. For eSCO packet types this make a
bit more sense since you might wanna control the bandwidth. However
changing them later is just pointless. And I don't recall of any profile
actually mentioning about it. I think they had a great idea behind eSCO
support, but since it is impossible to get the negotiation parts right,
everybody sticks with simple eSCO channels and doesn't bother to change
them.

And even if we would be going for a setsockopt(), that would be blocking
and then again pretty much pointless API. The sockaddr is most logical
thing that fits into what we wanna achieve. Disallow/allow certain
packet types and essentially force SCO over eSCO.

Regards

Marcel



  reply	other threads:[~2010-02-17 17:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-11 19:54 [PATCH] Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections Nick Pelly
2010-02-11 19:59 ` Nick Pelly
2010-02-15 21:15   ` Nick Pelly
2010-02-17  9:30     ` Ville Tervo
2010-02-17 16:49       ` Nick Pelly
2010-02-17 17:31         ` Marcel Holtmann [this message]
2010-02-18  6:49           ` Ville Tervo
2010-02-18 23:47           ` Nick Pelly
2010-02-19  8:08             ` Ville Tervo
2010-02-19 21:23               ` Nick Pelly
2010-02-22  7:53                 ` Ville Tervo
2010-02-26  1:05                   ` Nick Pelly
2010-02-26  9:20                     ` Iain Hibbert
2010-03-19 18:48                     ` smcoe1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1266427894.8849.66.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=npelly@google.com \
    --cc=ville.tervo@nokia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).