[pulseaudio-discuss] [PATCHv2 27/60] bluetooth: Create pa_bluetooth_transport for BlueZ 5 support

[Tanu Kaskinen]

On Fri, 2013-08-16 at 18:32 +0300, Tanu Kaskinen wrote:
> On Tue, 2013-08-13 at 01:54 -0300, jprvita at gmail.com wrote:
> >  static void device_free(pa_bluetooth_device *d) {
> > +    unsigned i;
> > +
> >      pa_assert(d);
> >  
> > +    for (i = 0; i < PA_BLUETOOTH_PROFILE_COUNT; i++) {
> > +        pa_bluetooth_transport *t;
> > +
> > +        if (!(t = d->transports[i]))
> > +            continue;
> > +
> > +        d->transports[i] = NULL;
> > +        transport_state_changed(t, PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED);
> > +        /* TODO: check if there is no risk of calling
> > +         * transport_connection_changed_cb() when the transport is already freed */
> > +        pa_bluetooth_transport_free(t);
> 
> IMO pa_bluetooth_transport_free() should be called by the transport
> code, because the backend also creates the transport. The backend may
> need a callback for getting notified about the device going away. Or
> perhaps there should be pa_bluetooth_transport_kill(), with a kill()
> callback in the backend. This would be similar to how sink inputs are
> killed if the sink they're connected to goes away.
> 
> If the backend is responsible for calling pa_bluetooth_transport_free(),
> the core should still ensure that t->device is set to NULL and that the
> transport is removed from discovery->transports (feel free to create
> pa_bluetooth_transport_unlink() for this purpose, if you want).

I'll add that it would be good to have the bluez transport backend in a
separate file, so that there would be clear separation with the
"bluetooth core" code and the transport backends.

-- 
Tanu