2011-08-25 10:09:05

by Arnaud Mouiche

[permalink] [raw]
Subject: [Patch Bluez] HFP gateway: fix failure on very first GSM connection

This patch fix the very first incoming connection from a GSM device
(playing the gateway role), when 'device->gateway' is NULL (when we didn't
perform a SDP browse request yet)

we add the service with 'btd_device_add_uuid(device->btd_dev, remote_uuid)'
but we provide HFP_HS_UUID as remote_uuid. Consequently, the HFP headset
service is activated instead the gateway service.

Note: I failed to know which UUID is the good one to provide for
audio_device_request_authorization()

Signed-off-by: Arnaud Mouiche <[email protected]>
---
audio/manager.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/audio/manager.c b/audio/manager.c
index 911af45..b356ed0 100644
--- a/audio/manager.c
+++ b/audio/manager.c
@@ -575,8 +575,8 @@ static void hf_io_cb(GIOChannel *chan, gpointer data)
return;
}

- server_uuid = HFP_AG_UUID;
- remote_uuid = HFP_HS_UUID;
+ server_uuid = HFP_HS_UUID;
+ remote_uuid = HFP_AG_UUID;

device = manager_get_device(&src, &dst, TRUE);
if (!device)
--
1.7.0.4



2012-03-15 14:55:11

by Mikel Astiz

[permalink] [raw]
Subject: RE: [Patch Bluez] HFP gateway: fix failure on very first GSM connection

Hi Johan,

> >
> > Any reason this patch was not picked up?
>
> Human error (me forgetting about it). The patch has been applied now
> (after fixing up the commit message), however it doesn't seem like too
> many people have missed this since the patch has been lying around for
> about half a year.
>
> Johan

Actually this patch solves the underlying issue I was trying to solve in my recent series "audio: enabling both Headset and Gateway", which had no feedback.

So it's not necessary anymore, but I still wonder if device_remove_drivers is doing the proper thing when unloads drivers entirely just because one of its profiles has been removed (see "[PATCH v0 2/3] Add device driver support for partial unloading").

Cheers,
Mikel

2012-03-15 10:16:25

by Johan Hedberg

[permalink] [raw]
Subject: Re: [Patch Bluez] HFP gateway: fix failure on very first GSM connection

Hi,

On Tue, Mar 13, 2012, Mike wrote:
> On Thu, Aug 25, 2011 at 5:09 AM, Arnaud Mouiche
> <[email protected]> wrote:
> > This patch fix the very first incoming connection from a GSM device
> > (playing the gateway role), when 'device->gateway' is NULL (when we didn't
> > perform a SDP browse request yet)
> >
> > we add the service with 'btd_device_add_uuid(device->btd_dev, remote_uuid)'
> > but we provide HFP_HS_UUID as remote_uuid. Consequently, the HFP headset
> > service is activated instead the gateway service.
> >
> > Note: I failed to know which UUID is the good one to provide for
> > audio_device_request_authorization()
>
> Any reason this patch was not picked up?

Human error (me forgetting about it). The patch has been applied now
(after fixing up the commit message), however it doesn't seem like too
many people have missed this since the patch has been lying around for
about half a year.

Johan

2012-03-13 15:17:50

by Mike Brudevold

[permalink] [raw]
Subject: Re: [Patch Bluez] HFP gateway: fix failure on very first GSM connection

Hi,

On Thu, Aug 25, 2011 at 5:09 AM, Arnaud Mouiche
<[email protected]> wrote:
> This patch fix the very first incoming connection from a GSM device
> (playing the gateway role), when 'device->gateway' is NULL (when we didn't
> perform a SDP browse request yet)
>
> we add the service with 'btd_device_add_uuid(device->btd_dev, remote_uuid)'
> but we provide HFP_HS_UUID as remote_uuid. Consequently, the HFP headset
> service is activated instead the gateway service.
>
> Note: I failed to know which UUID is the good one to provide for
> audio_device_request_authorization()

Any reason this patch was not picked up?

Mike