Thanks for your information. Let me try to backport from 3.18.
Regards,
Hieu Le.
On Sat, Aug 20, 2016 at 7:32 PM, Tanu Kaskinen wrote:
> On Sat, 2016-08-20 at 14:14 +0200, Georg Chini wrote:
> > On 20.08.2016 13:40, Tanu Kaskinen wrote:
> > >
> > > On Fri, 2016-08-19 at 13:57 +0700, Hieu Le wro
On Sun, 2016-08-21 at 15:19 +0300, Tanu Kaskinen wrote:
> One thing that needs fixing is the profile waiting logic - we wait
> until all supported profiles are connected (or until a timeout
> expires) before loading module-bluez5-device. Since we will now
> connect only HFP or HSP, it doesn't mak
On Sun, 2016-08-21 at 16:16 -0400, James Bottomley wrote:
> The v1.6 version of the standard contains a diagram
> which shows the minimum dialog you need.
For this standard:
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193
it's figure 4.1 (service level connection establi
On Sun, 2016-08-21 at 23:01 +0300, Tanu Kaskinen wrote:
> On Sat, 2016-08-20 at 15:05 -0700, James Bottomley wrote:
> > +static int hfp_rfcomm_handle(int fd, pa_bluetooth_transport *t,
> > const char *buf)
> > +{
> > +struct hfp_config *c = t->config;
> > +int val;
> > +
> > +/* statefu
On Sat, 2016-08-20 at 15:05 -0700, James Bottomley wrote:
> +static int hfp_rfcomm_handle(int fd, pa_bluetooth_transport *t, const char
> *buf)
> +{
> +struct hfp_config *c = t->config;
> +int val;
> +
> +/* stateful negotiation */
> +if (c->state == 0 && sscanf(buf, "AT+BRSF=%d",
On Sun, 2016-08-21 at 21:03 +0300, Tanu Kaskinen wrote:
> On Sun, 2016-08-21 at 15:19 +0300, Tanu Kaskinen wrote:
> > On Sat, 2016-08-20 at 15:03 -0700, James Bottomley wrote:
> > > static const char* const valid_modargs[] = {
> > > "path",
> > > +"disable_profile_hfp",
> >
> > We try to
On Sun, 2016-08-21 at 15:19 +0300, Tanu Kaskinen wrote:
> On Sat, 2016-08-20 at 15:03 -0700, James Bottomley wrote:
> > static const char* const valid_modargs[] = {
> > "path",
> > +"disable_profile_hfp",
>
> We try to avoid negative option names on the basis that double
> negatives are
On Sat, 2016-08-20 at 15:03 -0700, James Bottomley wrote:
> When all headsets supported both HSP and HFP, life was good and we
> only needed to implement HSP in the native backend. Unfortunately
> some headsets have started supporting HFP only. Unfortuantely, we
> can't simply switch to HFP only