[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 <redacted>
---
 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

Hi,

On Thu, Aug 25, 2011 at 5:09 AM, Arnaud Mouiche
[off-list ref] 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

Hi,

On Tue, Mar 13, 2012, Mike wrote:

On Thu, Aug 25, 2011 at 5:09 AM, Arnaud Mouiche
[off-list ref] wrote:

quoted

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

Hi Johan,

quoted

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