[pulseaudio-discuss] [RFC next v0 04/11] bluetooth: Add embedded BlueZ backend inside bluetooth-util

[Tanu Kaskinen]

On Wed, 2013-05-15 at 10:46 +0200, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
> 
> BlueZ 5 supports external profiles, meaning that certain Bluetooth
> profiles (e.g. HFP/HSP) are completely handled outside BlueZ.
> 
> However, some other profiles (i.e. A2DP) are still implemented inside
> BlueZ, so let's keep a BlueZ-specific backend inside bluetooth-util.
> 
> Furthermore, in the case of BlueZ 4, this embedded backend also supports
> HSP/HFP.
> ---
>  src/modules/bluetooth/bluetooth-util.c | 36 ++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
> index 56156a9..9f7cf77 100644
> --- a/src/modules/bluetooth/bluetooth-util.c
> +++ b/src/modules/bluetooth/bluetooth-util.c
> @@ -96,6 +96,9 @@ struct profile_data {
>      void *backend_private;
>  };
>  
> +typedef struct bluez_backend_private {
> +} bluez_backend_private;

I'd drop at least "private" from the name, because there isn't any
public counterpart. "backend" feels a bit redundant too, so I would go
with plain "bluez" (or "pa_bluez", if this moves to a separate file). I
can see that such name might feel awkward, though, so I'd be OK with
"bluez_backend" too.

> +
>  struct pa_bluetooth_discovery {
>      PA_REFCNT_DECLARE;
>  
> @@ -109,6 +112,8 @@ struct pa_bluetooth_discovery {
>      struct profile_data profiles[PA_BLUETOOTH_PROFILE_COUNT];
>      pa_hook hooks[PA_BLUETOOTH_HOOK_MAX];
>      bool filter_added;
> +
> +    bluez_backend_private backend_private;

If there are going to be multiple backends, I think the field name
should contain "bluez" in it to distinguish it from other backends.
Perhaps even bare "bluez" would be good as the field name.

>  };
>  
>  static void get_properties_reply(DBusPendingCall *pending, void *userdata);
> @@ -1975,6 +1980,33 @@ static DBusHandlerResult endpoint_handler(DBusConnection *c, DBusMessage *m, voi
>      return DBUS_HANDLER_RESULT_HANDLED;
>  }
>  
> +pa_bluetooth_backend bluez_backend = {
> +};

I wouldn't actually want to have the pa_bluetooth_backend struct at all.
You use it for storing callbacks, but the callbacks could as well be
part of pa_bluetooth_transport. As an analogy, we don't have
pa_sink_backend struct either, the sink callbacks are part of pa_sink.

-- 
Tanu