Hi Tanu, On Fri, Dec 14, 2012 at 10:24 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Wed, 2012-12-12 at 13:17 +0100, Mikel Astiz wrote: >> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >> >> The state of this interface is needed for one single reason: we need to >> wait until all profiles have been connected (or more precisely, until >> are connection attempts are finished). This can be made more explicit in >> the code by just checking the CONNECTING state (and not loading >> module-bluetooth-device during that state), but otherwise treating all >> transport types equally. >> >> Ideally, audio_state should be completely removed but it's left there to >> avoid an issue with module-card-restore, as documented in the source >> code's comments. > > I remember seeing some discussion recently at #bluez about keeping the > device state "connecting" until all profile connection attempts are > finished. Is that now the official plan? So it may not be necessary to > modify module-card-restore to handle the removal of the org.bluez.Audio > interface? Actually no, there is no plan to support anything similar to the old Audio interface. We discussed this several times and the conclusion was that BlueZ cannot solve this problem completely: if the connection is initiated by the remote device, there is no way org.bluez.Audio or a similar interface could tell if all profiles have been connected. So the conclusion was that this is something that needs to be handled outside BlueZ, in this case inside PulseAudio. This conclusion was reached after I asked in #pulseaudio if module-card-restore could be modified to handle the case where a card is loaded before all profiles get connected (which is the scenario we were trying to avoid by using org.bluez.Audio). The feedback was that yes, it should be possible, so that's why we decided to keep the 5.0 API simple. If anybody has a counter argument to make such a change in PulseAudio, this would be a good moment to state it, before BlueZ 5.0 gets released. Cheers, Mikel
