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
