Hi Tanu, On Fri, May 10, 2013 at 10:01 AM, Tanu Kaskinen <tanu.kaskinen at intel.com> wrote: > On Fri, 2013-05-10 at 09:06 +0200, Mikel Astiz wrote: >> Hi Tanu, >> >> On Fri, May 10, 2013 at 7:48 AM, Tanu Kaskinen <tanu.kaskinen at intel.com> wrote: >> > On Mon, 2013-04-29 at 18:28 +0200, Mikel Astiz wrote: >> >> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >> >> >> >> Register the HSP/HFP endpoints in BlueZ 5 Media API for the sake of >> >> completeness, despite the fact that there's currently no known user of >> >> such an endpoint. >> >> --- >> >> src/modules/bluetooth/bluetooth-util.c | 5 ----- >> >> 1 file changed, 5 deletions(-) >> >> >> >> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c >> >> index e3de01e..e46cbda 100644 >> >> --- a/src/modules/bluetooth/bluetooth-util.c >> >> +++ b/src/modules/bluetooth/bluetooth-util.c >> >> @@ -911,11 +911,6 @@ static void register_endpoint(pa_bluetooth_discovery *y, const char *path, const >> >> static void register_adapter_endpoints(pa_bluetooth_discovery *y, const char *path) { >> >> register_endpoint(y, path, A2DP_SOURCE_ENDPOINT, A2DP_SOURCE_UUID); >> >> register_endpoint(y, path, A2DP_SINK_ENDPOINT, A2DP_SINK_UUID); >> >> - >> >> - /* For BlueZ 5, only A2DP is registered in the Media API */ >> >> - if (y->version >= BLUEZ_VERSION_5) >> >> - return; >> >> - >> >> register_endpoint(y, path, HFP_AG_ENDPOINT, HFP_AG_UUID); >> >> register_endpoint(y, path, HFP_HS_ENDPOINT, HFP_HS_UUID); >> >> } >> > >> > So there was some discussion about whether to do this or not? Could >> > someone reiterate the arguments for and against, or point to a relevant >> > thread in the mail archive? >> >> The argument in favor of merging these last patches is about feature >> completion, as argued in [1]. BlueZ 5's Media API was designed in a >> way that an external telephony component could use it and >> automatically interact with PulseAudio. In this scenario, BlueZ not >> only defines the API but it also acts a component registry, in >> particular for org.bluez.MediaEndpoint instances which PulseAudio >> implements (to be more precise, the two endpoints for HFP/HSP, which >> are now subject of discussion). >> >> oFono was the first telephony component addressing this approach but >> in the early stage of implementation, it was decided that this D-Bus >> mechanism was not desirable. Instead, a oFono-specific API was >> designed to handle the interactions between oFono and PulseAudio (or >> other audio components). Therefore, there is no current user of BlueZ >> 5's MediaEndpoint1 for HFP/HSP, except for old development branches of >> oFono. >> >> > >> > To me the important question is: if there was a user for these >> > endpoints, would the current code in PulseAudio work? >> >> There was a time when this patchset was working with a branch of >> oFono, although these patches never made upstream. It's still quite >> likely that issues exist and it's always going to be difficult to >> maintain a codebase without active users, so I see the point about >> leaving this endpoint out until someone actually has real interest in >> it. > > Right, I agree that we should avoid code that isn't used, so I will not > push this patch. Was it so that also the rest of the set is then not > necessary? As explained in the cover-letter, the decision involves the last 5 patches, that is, v4 12/16, 13/16, 14/16, 15/16 and 16/16. Cheers, Mikel